Re: Show me the Virrii!

["Exibar" <exibar () thelair com>]

Although I agree with your other points, I have this comment:

Why do you ultimately blame Windows/DOS for the virus problem?  This is
simply not true.  Are there not SQL worms?  Was it not a SQL worm that was
the fastest to spread in history?  Are there not many Linux worms and
viruses, and more being written each day?  Are there not viruses and/or
worms that exploit Cisco products?  Hell there are even worms that exploit
FTP and IRC!  I can go on.

   It is not Windows that is the problem.  It is the people that write the
damned things that is the problem.  Ok, perhaps it's the lack of laws that
will make a programmer think twice about becoming a Vx'r.

   If Linux had the marketshare that Windows does right now, and it just
might one day it's hard to compete with free, and the majority of viruses
are being written for Linux, would you then blame Linux as the cause of the
problem?

  Saying Windows is to blame for the mess that we're in is like saying the
gun is what causes a murder and not the person that pulled the trigger.

  Exibar

----- Original Message ----- 
From: <John.Airey () rnib org uk>
To: <full-disclosure () lists netsys com>
Sent: Wednesday, January 07, 2004 5:15 AM
Subject: RE: [Full-disclosure] Show me the Virrii!


> > -----Original Message-----
> > Date: Mon, 05 Jan 2004 09:09:57 -1000
> > From: Jason Coombs <jasonc () science org>
> > Reply-To: jasonc () science org
> > Organization: SCIENCE.ORG
> > To: Richard Maudsley <r_i_c_h () btopenworld com>
> > CC: full-disclosure () lists 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 () science 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 () rnib 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
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html