lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <411C6CDF.15746.ADC8D875@localhost>
From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: AV Naming Convention

Brad Griffin wrote:

<<snip>>
> Using a generic no-name description in an identity file until a
> committee named a virus variant would unsettle millions of end users
> ("you've got a virus, but I'm buggered if I know what it's called").

Indeed, this is a factor I've not even touched on as I've mainly been 
discussing larger, more structural issues.

Another twist on it would be that you'd get bunches of confused folk 
running round saying things like "the Symantec-20040813-017 virus does 
X" while another bunch would be ringing NAI tech support asking "What 
does the Norman-20040813-022 virus do?  Our gateway virus scanner has 
stopped hundreds in the last hour and if we release one from Email 
quarantine and unpack the attachment your desktop scanner doesn't 
detect anything" and on and on and on.

Also, there is a very strong sentiment in the industry (that much tech 
support experience indirectly suggests is well-founded) that users 
"want" (even "need") relatively easy to remember names and things like 
Symantec-20040813-017 and Norman-20040813-022 certainly don't fit that 
bill.

> (MY couple cents of useless input).

Not at all -- a good point previously overlooked/ignored.  It is 
another part to the "the largest cost of naming inconsistency occurs 
during the first few hours of 'outbreak' events" issue.

> IIRC, haven't a lot of the naming convention problems occurred because
> the majority of vendors don't like to pander to vxer's egos by naming
> viruses the way the creators' wanted?

I guess that depends how you define "a lot".  Certainly some naming 
inconsistencies are due to some vendors happily choosing the name 
suggested in some comment in a virus' code or displayed in a message, 
or otherwise "obviously manifested" by the virus (some hardcoded 
filename, hardcoded Email message Subject: line or distinctive message 
body word, etc, etc).  Of course, whether you agree that choosing such 
names for the "official" malware name strokes its writer's ego or not, 
there are sound _technical_ reasons for not using such ephemeral 
"features" of the code as the basis for choosing a name.

For example, imagine the FooBar.A virus contains the text message in 
its body (but has no code to display the message or even to access the 
address range the message will be loaded into memory at) "I am the 
FooBar virus", and that was the basis of the original family naming 
choice.  Now some half-wit (i.e. 95+% of "virus writers") comes along, 
exercises his mad hacking skills by firing up his favourite, leet 
hacking tools (i.e. a hex editor), opens a sample of the virus, 
modifies the message string to now read "I am the BarFoo virus" and 
releases it.  Should we call this "new" virus:

A.  FooBar.A because the only change is not only to a non-code area, 
but to a data area that is never referenced by any code in any 
(functional) branch of code, so this "new variant" is really only just 
the original based on the code-invariance rule.

B.  FooBar.B because it is clearly very similar to (in fact, has 
precisely the same replication code as), yet different from, FooBar.A.

C.  BarFoo.A because "BarFoo" is "clearly" the virus writer's intended 
name.

D.  BarFoo.A because "BarFoo" is "clearly" the virus writers intended 
name and you work for VendorY who has not seen FooBar.A yet and is 
unaware of both its existence and that VendorX has named it FooBar.A.

E.  Heaven knows what, but there's bound to be at least three or four 
more-or-less "obvious" other names to use, so why not use one of them? 
Recall that just because VendorX has already seen and analysed FooBar.A 
this "new" variant may be seen first by VendorY who may be unaware of 
both the existence of FooBar.A and VendorX's choice of name for it.

F.  Garfield.B and you rename FooBar.A to Garfield.A because you now 
realize that "FooBar" was a stupid family name for these viruses, there 
is no other "obvious" name that is not based on trivially ephemeral 
features of the virus, and you always had a hankering to name a virus 
after that annoying kid from your first year at high school who...

G.  LesboSex because you're sick of all these rubbish viruses you've 
had to analyse and add detection of lately, and you think that is a 
good joke to pull at the virus writers expense.

The "science" of virus analysis and classification cannot answer this 
question so there really is no "correct" answer (though there is at 
least one "obviously incorrect" one and one that I'd hope should 
obviously be my preferred one).  If you put the scenario (but without 
the multi-choice options) to several virus analysts working on AV 
products you would (mainly) get answers A. and B..  Despite that 
though, in the real world, A. through E. is what actually happens and 
very occasionally F. (actually, G. kind of happened too, though I've 
taken a few liberties with the scenario...).

Sadly, despite us all knowing that A. through E. is "everyday reality" 
many AV companies do not have sufficiently flexible structures and 
processes in place to allow for the easy renaming of malware should 
their initial (published) choice of name turn out to be a poor one 
(which, in case my preference in such cases is not already clear, 
partly explains the undesirably low rate at which F. actually happens).


-- 
Nick FitzGerald
Computer Virus Consulting Ltd.
Ph/FAX: +64 3 3529854


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ