From: John.Airey at rnib.org.uk (John.Airey@...b.org.uk)
Subject: Show me the Virrii!

> -----Original Message-----
> Date: Mon, 05 Jan 2004 09:09:57 -1000
> From: Jason Coombs <jasonc@...ence.org>
> Reply-To: jasonc@...ence.org
> Organization: SCIENCE.ORG
> To: Richard Maudsley <r_i_c_h@...penworld.com>
> CC: full-disclosure@...ts.netsys.com
> Subject: Re: [Full-Disclosure] Show me the Virrii!
> 
> Richard Maudsley wrote:
> > I recently finished a stable version of my little 
> Virus-Scanner, LMS (
> > http://www.mindblock.org/lms ).
> > It currently detects 19 viruses. I need it to detect hundreds.
> > 
> > How do big Anti-Virus companies get their hands on new viruses, and 
> > how
> > can I?
> 
> Antivirus software is one of the biggest frauds going in the software 
> industry. You really don't want to go there. Consider 
> something useful 
> instead:
> 
> (from http://www.windevnet.com)
> 
> Antivirus Software Turned Upside Down
> by Jason Coombs (jasonc@...ence.org)
> 
> Antivirus software exists because viral code and malware 
> exist. Malware 
> signature databases coupled with antivirus software provide what I'll 
> call "matter of fact, after the fact" security. It is a 
> matter of fact 
> that bytes matching an a/v vendor's malware signature must have 
> malicious potential resembling a known virus, worm, Trojan, or other 
> code analyzed in the past by the a/v software vendor and labeled as 
> harmful. While false positives do occur in practice, a virus scanner 
> wouldn't be useful if it constantly failed to distinguish between 
> malware and user data or desireable code. Therefore, a/v software 
> becomes the best proof, in practice, that particular bits are 
> hostile. 
> No jury is likely to reject forensic testimony designed to 
> establish the
> 
> presence of malware after seeing a forensic examiner employ a trusted 
> brand-name a/v scanner to detect a virus or Trojan on a hard drive or 
> other storage device. A commercial virus scanner makes a terrific 
> exhibit in front of a jury. As a result, there is a distinct 
> possibility
> 
> that civilian security researchers may help to convict hackers (and 
> other civilian security researchers) of computer crimes 
> simply by adding
> 
> definitions to a virus signature database. Law enforcement 
> simply lack 
> the resources necessary to assemble definitive lists of 
> criminally-malicious bits, so we end up with an interesting, and 
> uncomfortable, overlap between private sector business 
> decisions and law
> 
> enforcement investigations.
> 
> Antivirus software vendors make no effort to conceal the fact 
> that they 
> are in the business of selling virus signature updates. They sell 
> content more than software, and it is content updates that 
> drive their 
> profits. Updates to virus definitions occur after the fact, 
> so everyone 
> is always out-of-date and must keep paying in order to feel 
> protected. 
> This makes for a good business, but it doesn't make for very good 
> security. In fact, it's completely backwards. Think about it for a 
> moment, why should anyone go through the expense and the trouble of 
> keeping a running list of all bad code ever encountered? We can prove 
> that something is good just as easily as we can prove that 
> something is 
> bad, but publishing a list of all known good software 
> wouldn't be very 
> profitable. Few people would ever have a need for the entire 
> database. 
> Most people would have no need for updates unless they planned to 
> install more software. Restricting the execution of code by a 
> CPU to a 
> small list of known good programs that the owner of the 
> computer chooses
> 
> to trust would basically kill the antivirus industry. Such a 
> deny-first 
> security policy would give computer owners the kind of control over 
> their boxes that the introduction of automobile ignition keys gave to 
> early motorists. The fact is that today's computers are still 
> designed 
> to accomodate arbitrary drivers as though the absence of 
> security is a 
> feature demanded by the marketplace.
> 
> This brings to mind the purportedly-true story of the 
> evolution of the 
> automobile seatbelt. You've probably heard that consumers resented 
> seatbelts initially, and manufacturers didn't want to install them, 
> because they gave the impression that there was danger involved in 
> driving a car. Compared to the seatbeltless horse or bicycle, 
> a car with
> 
> a seatbelt looked scary, and car manufacturers weren't in the fear 
> business, they sold convenience and other delightful things. I'm not 
> going to take the time to track down a definitive answer to 
> the question
> 
> of the authenticity of this historical tale, if it isn't true then 
> perhaps it should have been. Rhetoric is always better when 
> it's mostly 
> true. The point is that computing can't continue without 
> seatbelts. We 
> simply cannot let our CPUs continue to execute whatever 
> happens to come 
> along each day. If you've ever tried to assemble a list of 
> the processes
> 
> normally executed by one of your Windows boxes, so that you might be 
> able to spot a suspicious process that wasn't there before, you've 
> probably realized that a malicious process can come and go 
> faster than 
> the Windows Task Manager will refresh. And Task Manager 
> doesn't bother 
> to keep a record of past program executions, so you'll only spot a 
> suspicious process in this way if it happens to be long-lived 
> or if you 
> audit process execution at just the right time. Putting aside for a 
> moment the obvious need for better low-level hardware-based controls 
> over code execution, is there really any reason for Windows to allow 
> programs to execute without first requiring the end-user or an 
> administrator to authorize them in advance using a simple software
> control?
> 
> If we add even the simplest software seatbelt to the boxes we drive 
> every day, we can turn antivirus software upside down, replacing it 
> instead with anti-software software. Not unlike the 
> anti-driver purpose 
> served by automobile ignition keys, or the anti-death purpose 
> served by 
> seatbelts, we must redesign our infosec safety precautions around the 
> idea that the bad things that can happen are worse than the 
> protections 
> we must have to guard against them. Nobody would accept an 
> out-of-date 
> list of ways in which one can die in an automobile in lieu of a 
> seatbelt, so why do we accept that an out-of-date list of bad 
> code is a 
> viable way to protect ourselves while we drive a computer?
> 
> To complete what turned out to be a three-part-series on using hash 
> algorithms for code authentication and containment, below I offer a 
> working prototype of a software seatbelt for Windows. The last two 
> articles in this newsletter laid the foundation for forensic 
> hash sets 
> produced using the MD5 or SHA-1 hash algorithms and comprehensive, 
> full-file hash digests as a replacement for the Microsoft 
> plan to some 
> day make digital signatures work perfectly. Software vendors should 
> communicate hash sets to users, and users should assemble and 
> periodically verify hash sets of code modules installed on Windows 
> boxes. But we also need runtime verification of hashes against our 
> trusted hash sets. That's what the prototype below is designed to 
> accomplish, albeit very crudely. The best way for runtime hash 
> verification to occur is doubtless with the assistance of hardware 
> enhancements to CPU and motherboard architecture. No add-on, 
> after-the-fact technique to inject hash verification (or antivirus 
> scanning, for that matter) into Windows will ever be as good 
> as a simple
> 
> kernel modification. Still, the code shown below isn't a 
> complete waste 
> of time. I've been using a precursor to this code for a 
> while, without 
> the hash verification feature, and feel that it gives a 
> valuable log of 
> executable modules that are invoked on a box, if nothing 
> else. By adding
> 
> hash code profiling and verification based on the work shown 
> in the last
> 
> two newsletter articles this code begins to look more promising. At 
> least as a source of ideas and code.
> 
> [snip code example]

I think the example of seatbelts is a poor one (and so is the use of the
word evolution, but then again, nearly everyone else abuses that word
without having a clue what they are talking about). it's especially poor
considering that few (if any) Americans actually use a seatbelt, preferring
instead to trust their lives to a controlled explosion going off in their
face.

A better example would be prisons. We put in prison those that we believe to
be guilty of criminal acts. Most of the time we get it right.

To imprison everyone, and then only free the ones that you trust would not
be viable (although it should be noted that it appears that America is
trying just this). Taking into account the accuracy of such decisions, you
would most probably free more criminals than were imprisoned before.

Indeed, the current situation is not good. Anti-virus companies are
basically making money out of criminal acts. But so are private prison
companies, the courts, lawyers etc. What makes the anti-virus industry
unique is that each company shares information with all its competitors. I
can't think of another industry that does this.

We have reached a stage now where anti-virus products alone do not protect
our data. Thousands of machines can be infected with a virus before an
update is released. However, reversing this and only running "trusted" code
would give us far more difficulties. What if a malicious program gets
"trusted". How can it be "untrusted" again? 

We have already seen cases of security certificates being issued to someone
who supposedly worked at Microsoft. So if you have an "approval" process,
you need an "unapproval" process, which puts us back where we started! Who
will control the "approval/unapproval" process, and how could they escape
anti-trust laws? The only companies I can think of with the expertise to do
this collaboratively are the same anti-virus companies you criticise. They'd
probably even charge *more* for the service. 

Your proposal sounds very much like palladium, which carries the same fatal
design flaws.

As for your first point about anti-virus databases being tampered with to
force a wrongful prosecution, do you have any evidence of this? Such antics
in the UK would be a criminal act, known as "attempting to pervert the
course of justice" which carries a prison sentence. Fabricating evidence is
a serious crime in many other countries too.

In fact, all a defence would have to do is show that other anti-virus
vendors don't detect the code as a virus. More evidence in the defendant's
favour will sway any jury. Anti-virus companies currently accept submissions
from software companies whose products generate a false positive, so I'm at
a loss to see how this could ever be successful.

A better proposal would have been to disconnect the Internet. Without it,
we'd never have such rapid virus propagation, but of course then we wouldn't
be having this discussion. 

Hopefully we all realise that it is the fundamental design of Windows/DOS
that is mostly responsible for the mess we are in, but most of the world is
hooked on it now. Unless that situation changes, we are pretty much stuck on
the AV-update treadmill.

- 
John Airey, BSc (Jt Hons), CNA, RHCE
Internet systems support officer, ITCSD, Royal National Institute of the
Blind,
Bakewell Road, Peterborough PE2 6XU,
Tel.: +44 (0) 1733 375299 Fax: +44 (0) 1733 370848 John.Airey@...b.org.uk 

Even if you win the rat race, that will still only make you a rat.

- 
DISCLAIMER: 

NOTICE: The information contained in this email and any attachments is 
confidential and may be privileged. If you are not the intended 
recipient you should not use, disclose, distribute or copy any of the 
content of it or of any attachment; you are requested to notify the 
sender immediately of your receipt of the email and then to delete it 
and any attachments from your system. 

RNIB endeavours to ensure that emails and any attachments generated by 
its staff are free from viruses or other contaminants. However, it 
cannot accept any responsibility for any  such which are transmitted.
We therefore recommend you scan all attachments. 

Please note that the statements and views expressed in this email and 
any attachments are those of the author and do not necessarily represent 
those of RNIB. 

RNIB Registered Charity Number: 226227 

Website: http://www.rnib.org.uk 

Powered by blists - more mailing lists