Full Disclosure mailing list archives
Re: Show me the Virrii!
From: "Exibar" <exibar () thelair com>
Date: Wed, 7 Jan 2004 10:11:47 -0500
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 littleVirus-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
Current thread:
- Re: Show me the Virrii!, (continued)
- Re: Show me the Virrii! Jason Coombs (Jan 05)
- Re: Show me the Virrii! S G Masood (Jan 07)
- Re: Show me the Virrii! Nick FitzGerald (Jan 07)
- Re: Show me the Virrii! Richard Maudsley (Jan 07)
- RE: Show me the Virrii! VBuster (Jan 05)
- RE: Show me the Virrii! Richard Gadsden (Jan 06)
- Re: Show me the Virrii! Donze, Erich (Jan 06)
- RE: Show me the Virrii! Elsner, Donald, ALABS (Jan 06)
- RE: Show me the Virrii! John LaCour (Jan 06)
- RE: Show me the Virrii! John . Airey (Jan 07)
- Re: Show me the Virrii! Exibar (Jan 07)
- Re: Show me the Virrii! michael williamson (Jan 07)
- Re: Show me the Virrii! Exibar (Jan 07)
- RE: [inbox] Re: Show me the Virrii! Curt Purdy (Jan 07)
- Re: [inbox] Re: Show me the Virrii! Exibar (Jan 07)
- Re: Show me the Virrii! Exibar (Jan 07)
- Re: Show me the Virrii! Jason Coombs (Jan 05)
- Re: Show me the Virrii! Exibar (Jan 07)
- Re: Show me the Virrii! Exibar (Jan 07)
- RE: Show me the Virrii! doyle043 (Jan 07)
- RE: Show me the Virrii! Nick FitzGerald (Jan 07)