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: lists at michel-messerschmidt.de (Michel Messerschmidt)
Subject: Asynchronous, industry-wide virus naming scheme proposed

On Thu, Oct 02, 2003 at 02:21:21PM +0200, Feher Tamas wrote:
> My idea to solve the above dilemma is: why not implement a system for 
> industry-wide virus identification, called Virus Name System (VNS), 
> somewhat similar in its nature to the distributed Domain Name System 
> (DNS) of the Internet. Numerical (abstract) virus ID would be analogous 
> to the IP address and virus names replace the host name. 

Actually you're not the first who has thought of a DNS-like 
Virus Naming System. 
But there are significant differences between hostnames and virus names. 
While DNS binds a name to a single, unique IP number, 
virus researchers may get many samples of the same new virus in very
short time, that must all be mapped to the same name. 
Additionally it may be difficult to decide if two samples are actually 
the same virus. So a "first-come, first-serve" strategy like DNS may
even lead to more meaningless virus names without solving any other
basic problem.


> Just like a 
> particular IP address can have several host names associated with it, a 
> numerical virus ID could absorb two, three or seven virus names from 
> different vendors and allow for a dismissal of less-favoured names over 
> the time to keep the single real one. 

If researchers can't agree on a single name today, how should such a
system improve this situation. What's still missing is some criteria
how to select the "real one".
Therefore I don't see any advantage about current virus description
databases (that typically include common aliasnames).


> Inter-vendor discussions 
> conducted across the phone or the coffe table as to which name fits a 
> particular malware the best is not addressed in this paper.

So one of the major problems is not adressed.


> the virname system entries stored on root-VNS 
> servers should have records, formalized technical data, which is 
> verbose enough to determine if several differently named virus entries 
> submitted from diverse vendor virname servers are actually the same.

I think there exists no solution for this problem.


> Virus scanning software (the computer programs that customers buy) 
> should incorporate a new feature: when a malicious object is found, it 
> should ask the vendor-VNS server for the name of that malware, based 
> on a query with the virus name which is already hardcoded in its 
> signature database files. 

It's certainly a bad idea to require a network connection after
detecting an incident.


> If there is no match, it should fall back to the virus name which is found 
> hardcoded in its virus signature files. The substance is, the end user 
> and/or security administrator should be confronted with the most 
> authoritive name, whenever avilable.

The main problem is not to have the "most authoritive name", but to
identifiy the type of incident in order to eliminate the security
breach.


There are also some general considerations.
As you may know, it was proven impossible to generally detect every
virus. Taking into account the exponential growth of new malware,
how long will it be possible to classify and name every new piece of
malware ? Or must we rely more and more on generic detection (without
the possibility for a optimal solution) ?
In the long run it may be even more important to try to classify
all known good software.


-- 
Michel Messerschmidt           lists@...hel-messerschmidt.de
antiVirusTestCenter, Computer Science, University of Hamburg


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ