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]
From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: AW: Asynchronous,
 industry-wide virus naming scheme proposed

vogt@...senet.com replies to Feher Tamas:

> > Yet, I propose a project that reduces its scope to reaching a uniform 
> > and industry-wide virus name for any malware some 24-36h after the 
> > first discovery is still feasible and realistic.

I've just returned home from some extensive travels (including several 
detailed discussions of malware naming issues) and plan to post a 
detailed response to Feher's original message (which I have not read 
beyond skimming the first paragraph, noting its length and deciding it 
should wait till I have more time to give it more detailed attention) 
once I've caught up with all my Email and done a couple of days work...

> The weather frogs have this problem solved for as long as I can think.
> Of course, they don't have financial pressure to make the headlines,
> so the names don't have to be flashy.

However, I can quickly comment on this as it very simply will not work.

It will not work for one, or both, of two reasons...

The first is scale -- how many "tropical storms", hurricanes, etc do 
the met folk have a need to name each "season"?  A few dozen storms and 
at most around 10 to 20 hurricanes (per oecanic/geographic area).  The 
pre-defined list of names mechanism the met folk have adopted scales 
very nicely onto a problem set of that size.  But note that the 
existence of such storm systems (and thus the need to name them as they 
appear) are tightly defined by objectively _and easily_ measured 
criteria (sustained wind speeds through some unit of time), and even 
though these criteria differ from oceanic/geographic region to region, 
correct detection and anming is possible from anywhere that suitable 
meterological data are available.  Also, note that a detection delay of 
a few hours is probably not terribly critical (except, perhaps, to 
shipping in the immediate path of such storms, though even then, they 
tend to develop slowly relative to malware outbreaks and prudent 
skippers will set courses around apparently deepening storm systems).  
None of those factors come close to applying to today's fast-moving 
malware incidents -- we see many thousands of behaviourally or code-
wise similar mass-mailers, network share crawlers, pure network worms, 
etc per year with no way of telling a priori whether any particular one 
is likely to be one of those that "makes a lucky break" and thus 
"deserves" special attention to name selection; we have a great number 
of people all round the world working on the general "problem" of 
locating and adding detection of these things to their products who 
(unfortunately) do not talk amongst themselves as much as some of us 
would wish; and we have a fairly strong inclination to name these 
things in familial groups based on code similarity (which is really the 
second point, explained in more detail below).  further, in some cases 
there is no easy (filename, file size, hash, etc) way to objectively 
identify a specific piece of code as an instance of "the same code" as 
has already been named by some other researcher (tropical storms are 
easy in that they do not replicate wildly with samples of the same 
storm appearing at spots all over the globe while possibly employing 
self-modifying code routines that obscure the real natuure of the 
underlying storm system...)  In short, the scale of appearance of 
malware and thus also its rate of appearance, problems surrounding the 
identification of samples as exemplars, the non-objectivity of 
"severity" information and the widespread desire to correctly group 
malware familially all mitigate severely against adopting the naming 
approach that works so well in the entirely different and chronically 
weak, analogically, storm naming field.

The second problem is that malware is named taxonomically, so the 
"correct" name for a "new" piece of malware is partly dependent on the 
names already applied to previously analysed and named malware.  Rather 
inconveniently for the storm naming appraoch, it is not always the case 
that the first "notable" member of a family is the initial variant of 
that family.  The naming purists (and despite the mess across the 
industry as a whole, there actually are a few of these!) will insist on 
naming a subsequent variant of an existing family as such, and this 
alone simply will not fit the "predefined list of names" approach and I 
strongly believe that even if the other weaknesses of that approach, 
described above, could be reduced or eliminated, this alone is a major 
flaw of that approach that would discourage those who have historically 
shown the most concern for standardizing naming and for working toward 
better cross-vendor naming consistency.  "Penalizing" those who have 
worked hardest at improving malware naming is unlikely to prove very 
fruitful...


-- 
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