Nate Lawson <nateat_private> wrote: > I have been getting a lot of flames and veiled threats from individuals > and "virus researchers" for posting the code yesterday. There seems to be And you are surprised? I will be polite and alleviate you of much of your ignorance. You see, you are fundamentally ill-informed of some very important issues. These are issues that those in the antivirus industry deal with on an hourly basis, but that usually seldom impinge the consciousness of "ordinary systems managers". > a lot of misinformation going around so I wanted to clarify the situation. Well, there may be a lot of misinformation around, but I suspect most of it is not where you seem to believe it is... > These people are all producing the same arguments: Maybe because they have a better understanding of something than you ? Had that possibility dawned on you? > 1. "Posting the source allows someone to know how to write a Macro virus" > > Yes, and anyone of the 100,000 or more people who got the virus the other > day can buy VB and do File->Open and see the source. Repeat after me: > "Word macros are INTERPRETED". All symbol information is present. No > decompilation necessary. So? The reality is most people who *get* macro viruses do not want them. They do want them removed and they would rather not have any more. Most people so afflicted do *not* hanker to get their hands on the code and "play with it". The fact that this virus has become very widely distributed more quickly than any prior piece of malware is neither here nor there. Look in the newsgroups and chat rooms for the sad gits who *cannot* get it who desperately want it? Are you really providing any service than the anti-social one virus distributor by posting a public pointer to the code? > 2. "By reformatting the source, you have created a new variant" > > What? Your virus scanner could be thwarted by adding whitespace? Someone > has a problem but it isn't me. Perhaps you'd best learn from the sandbox > mechanisms of Java or virus scanners like F-PROT. A virus is not a virus > because it has the string "By 3le3t3 DudEZ" followed by three tabs. It is > a virus because it does things like update Normal.dot. Repeat after me: > "Pattern matching alone does not a virus scanner make". Just as in the > recent thread about security scanners doing version-checking instead of > exploiting a hole, the best answer is to use a combination of techniques > to identify flaws or malicious code and then notify the user of any > uncertainties in the detection mechanism. Indeed. The point is, though, that whitespace does make a difference and I'll show you why using your own example--F-PROT. First, let me say that I think F-PROT is a fine product, and were I to actually use any antivirus software on my own machines, I would certainly consider it. So, let us accept that F-PROT is a "good product". If someone took the code you posted and worked out how to make it infective (luckily, you did not actually post fully functional code) without changing the structure of your reformatted source at all, F-PROT should (I have not tested this and don't care to) detect W97M/Melissa.A (if you have the latest MACRO.DEF). This would also be true for several other products. There are some that will be thrown by those changes though. Your comment about virus scanning not being about "patter matching" is, of course, quite true, but your conclusion that products failing to detect W97M/Melissa.A because of such a trivial change is invalid. You see, you apepar to not understand the role of *identification*. There are two fundamental approaches to virus detection. Loosely, "generic detection" (integrity checkers, heuristic-only scanners, behaviour detectors/blockers) and "identification". Many products (including F-PROT) incorporate both. A simple way to make this distinction is the first approach is "something detection" and the second "'what' detection". The binary representation of your modified source in a Word document or template file is different from the original virus'. The way the virus is written means that it can only ever "naturally" be reproduced as an exact copy. Many of the "what detection" products therefore only identify the exact form. You deride them, but do not seem to understand that left to its own devices the virus will only exist in copies of that original form. As much for speed reasons as any, many products will take the "shortcut" of detecting the virus as it is and as it "should be". To do otherwise adds overhead to the product and remember, most of umpty-gazillion viruses that they will detect will never be seen in real-world infection incidents, so hindering the user with more overhead to cover ones tail for occasional and "unnatural" circumstances is not likely to be a popular design choice. So, in a sense you have made a new variant *and* despite your scoffing attitude to this, it is actually result of valid theoretical and design issues. You don't get off that lightly, however. You see, there is another good reason to do very precise identification of a virus. If the code is not exactly the code that you have seen before, then disinfecting it is hazardous. There may be new twists, information that has been saved from the pre-infection state that must be retrieved and restored as part of cleaning up, etc. The designers of F-PROT are particularly meticulous about such issues, though as I said above, in this case their product should not be "tripped up". But then, they have paid the performance price of dealing with some of these issues **as they pertain to macro viruses**. To castigate others for this "lack" in their product is somewhat unreasonable. > A perfect parallel to this is the Internet worm. We were reminded of that > time as we paused the Exchange SMTP service to keep the program from No--you are quite wrong there. You see, the worm exploited security holes in some popular products. This is a *virus*. Worms that are exploits are the function of poor design, poor implementation or both. Viruses are a function of general purpose computers. It is likely true that higher- functionality parallels a higher "viusability factor" and thus viruses in Word are likely to be easier to make because Word has a very high "functionality index". Publishing code for exploits seems likely to have the problems fixed. Publishing code for viruses won't. People will not move to less functional applications and platforms simply because viruses are possible. If you believe that, I have a nice block of land on Mars you may be interested in... Publishing virus source code will only have one nett effect--it will increase the number and idversity of viruses out there faster than they would otherwise increase. > spreading. Also, it was important to quickly analyze the program, making > sure it did nothing malicious like mailing a person's files to another Now you are making sense again. Sure--analyse the code. Discuss the anlaysis with other competent people in way sthat do not increase the likelihood of variants and copycats. I'm all for it. To be done well though, it requires an element of expertise. The antivirus industry and those of us closely affiliated with it have been doing this for years. We might even be considered somewhat "expert" at it. > location. After doing this, I believed the code itself would help others > do the same if they needed to. An important note is that the Symantec and If they had the virus they could get the code. If they did not have it, there were plenty of "good enough" descriptions of what the virus did to go by. The fact that several AV companies and several people independent of AV had pretty much the same independet analyses should tell the interested admin (or whoever) what the virus was capable of. > McAfee web pages describing the virus both left out important information > (for instance, avertlabs.com neglected to mention the active document and > Normal.dot file infection). If I had made any mistakes in my analysis, > another could have determined this for himself. The virus is a very ordinary macro virus. The significant thing about this one is how much disruption it can cause in large Outlook shops, and especially how much trouble it could cause in large Outlook/Exchange shops. The initial descriptions you refer to did leave out those points, but in the grand scheme of things that is not that important. People accustomed to dealing with macro viruses know that, know what to look out for and would have not been too worried about that. Your diligence on that point is to be commended and I'd suggest that simply posting a note to the effect that that important issue seemed to be missing from those vendor's descriptions would likely have won you kudos *and* seen the descriptions quickly fixed. Believe me, as past editor of Virus Bulletin, there is little the AV people like less than to be publicly shown up on such matters. > A good reference is the paper "With Microscope and Tweezers, An Analysis > of the Internet Worm" by Mark Eichin and Jon Rochlis. It can be found at: > > http://www.mit.edu:8001/people/eichin/www/virus/main.html It is a good analysis, but we are talking about something here that will not be "fixed" by you (or ten thousand others) "publicizing" the problem. Publishing buffer overflows in <insert favourite daemon here> will get those things fixed, but publishing Melissa's source will not cause MS to re-engineer their whole OS and most of their productivity applications. > In short, this is the same full disclosure vs. security through obscurity No, it is nothing like it. There are two *fundamental* differences. First, this is not a security issue in the traditional sense. Yes--I and masny, many others would love MS to give us a secure mechanism for disabling document-borne macros completely in Word. But writing viruses will not convince them they should do this. Thus, publishing virus source code won't either. People are all but forced to use MS's software, so this situation is likely to continue. Not defending, them's just the facts... Second, viruses spread. However, unlike worms which are (usually) self-spreading exploits, there is no "vulnerability" to be fixed. Thus, a virus is likely to keep spreading whereas a worm will die out. The antivirus industry has its own internal and safe distribution mechanisms for sharing viral code so as to maximize the protetction of the general user population. Publishing and public distribution have no part of that. > debate. Make your own decision what is appropriate; my mind has been made > up in regards to this for at least a decade. Viruses tend to be > uninventive and boring. This one was extremely unsophisticated, exploited > no new holes, and required user carelessness to spread. I only got And this does not tell you something about the nature of viruses? Note that they are all round (generally) much less challenging than typical security exploits. That is becasue they *are* unlike typical security exploits. That difference makes the handling of them different from the handling of typical security exploits. Independent of that difference, the fact that they self-replicate and will continue to do so for the foreseeable future means that not making them widely available is the only professionally responsible course of action. > involved because I had to help fend off the nuisance Friday. I hope > everyone found the postings useful and will demand better virus protection Your analysis was useful. You should have left it at that. > than string matching from their virus scanner vendor as well as request Indeed. Most AV products have long since moved past simple string scanning, but it can't hurt to ask yours... > that Microsoft add more virus prevention than "enable macros? yes/no" and Indeed. > disallow macros from doing things like sending mail or writing to files > without notice to the user. You can ask. You won't get it. Again, not defending. Part of the reason MS has been so successful is because they have this "policy" of allow anything from anywhere. You've heard of "Visual Basic everywhere"? Well, that's what it is about. It might be fine on a standalone machine or a machine that is part of a "standalone LAN" but the fact that anyone considers it might be a good idea to scale it to the enterprise just shows how much MS really cares about security. The trouble now though, is that MS's products are so well entrenched and so many installed systems depend on the simplicity this power and flexibility allows, that I cannot see anyone challenging MS product positions for sheer economic reasons. Given that inertia--as undesirable as it all is--you are only doing existing MS users a disservice by posting virus code, as that will only further exacerbate their current and short-/mid-term problems. Regards, Nick FitzGerald, Virus Bulletin.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:40:54 PDT