Re: Malicious code detection and full disclosure

[nick () virusbtn com (Nick FitzGerald)]

Nate Lawson <nate () ROOT ORG> 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.