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-next>] [day] [month] [year] [list]
From: etomcat at freemail.hu (Feher Tamas)
Subject: Asynchronous, industry-wide virus naming scheme proposed

Dear IT Security Community,

The June 2003 issue of the Virus Bulletin paper (page 13) contains a 
report about EICAR-2003 antivirus research conference in Copenhagen. 

The third paragraph says:
"she called for the implementation of industry standards, beginning 
with synergistic naming schemes. The suggestion of a numerical naming 
scheme for viruses prompted discussion amongst delegates - many 
agreed such a scheme would be a helpful solution, while others felt 
that their users would not respond as well to warnings about a 
numerically named virus as they would to viruses with more memorable 
names."

The autumn 2003 conference of computer virus researchers in Toronto 
also discussed malware ID woes, like conflicting names, media-flashy 
names vs. numeric/structured names, voluntary or standardized 
naming, privacy and copyright issues with virus names, etc. at great 
depth , but apparently without any breakthrough.

These examples show the real-world need for a viable solution. Well, I 
have a novel idea, which stems from the observation that zero-minute 
coherent virus naming is impossible.

Let me reason:
Considering the free market competition in the AV industry and the 
short timeframe between vendors receiving sample and releasing 
detection, few hours are available for naming newly discovered viruses. 
Considering the well-know computer science theorem, which says it is 
impossible to write a software, that successfully compresses each and 
any arbitirary file; it is impossible to coherently name viruses without 
vendors sharing full samples with each other, because information 
relevant to the process of naming malware may reside anywhere in the 
sample or even the decompiled source.

As you know, AV vendors only share samples among each other 
monthly. They guard their partially proprietary malware sample 
collection sets strictly. This situation is legitimate and is not going to 
change, period.

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 mean a virus name which 
can then be cascaded down, back to even the desktop AV programs 
and it will help alleviate the woes of the current name turmoil situation. 
Yes, it would be a kind of a minimalistic concept, but I hold that it shall 
be acceptable to all interested parties, which cannot be said of other 
proposals.

Of course, I know there are several difficulties to solve, but I think this 
system would blend well with the current, heavily segmented antivirus 
arena. It is taken for granted that AV vendors would never succumb to 
a monopoly-based standardized virus naming scheme, because it 
would give too much control to Microsoft, CERT or FBI or whoever else 
in control of the system.

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

Just like the current Net system of 13 root level DNS servers and 
thousands of lesser DNS servers, the virus naming network would be a 
distributed one, but inevitably less open. A handful of "root virusname 
servers" should be established, based on a geographical/cultural 
divisions on the globe. For example, it is well known that Asia, 
especially South Korea has a computer virus culture that is vastly 
different from the rest of the world. Locale specific DOS virii are still 
popular there, etc. Several root VNS servers can accomodate that.

Each of these "root" servers would be controlled by a voluntary group 
composed of the major AV vendors, those who are most significant in 
that geographical area and these servers would replicate among each 
other, according to predefined rules.

(Considering the need for comparative virus detection rate testing, etc. 
maybe a single super-root VNS server should be established, probably 
in the hands of the current V-Grep staff or some other independent 3rd 
party. But this should be a strictly write-only server, one that NEVER 
serves the public, to prevent abuse of power).

Each AV vendor would have its very own virusname server(s), where 
they upload their virus name and abstract ID record for all malware 
they detect. When the virus samples's data and name is uploaded from 
vendor server(s) to "root VNS" servers it becomes universally accepted. 
Of course this step requires human supervision!

Just like the Net DNS system contains miscellanous info to help 
identification, like owner name, owner's street address, domain 
registrar's name, etc.; 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 this detail is most problematic, may even defy solution. Luckily, 
this issue is only present in interoperation between vendor-VNS and 
root-VNS servers. The interoperation between antivirus software and 
vendor-VNS server is easy, as virus names are always unique and 
directly related within a single AV vendor.

This cannot be said with guarantee when speaking of several vendors. 
Therefore, formalized data must be maintained beyond each virus name 
entry. This is complicated, both technically and legally, I could think of in 
the likeness of a national registry of people's identity, where their 
names and photos are backed by their DNA sample. I may have a 
guess how to do this correctly, see the footnote (*) ]

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. If the VNS server replies with another, more 
authorative name (because the vendor-VNS has been synchronized 
with Root-VNS, where another name has been choosen for that 
particular malware) anti-virus software should display that industry-
wide name to the user, not the proprietary one.

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.

Protocol spoken between antivirus software and vendor-VNS servers 
should be a simple (probably http-based) one, where only vnames data 
is discussed. However, full protocol conducted between VNS-servers 
will be a more complex one (probably X.509/LDAP or SQL based) 
because both virusnames and abstract malware data will need to be 
negotiated. Whether or not conversation between anti-virus software 
and abritrary VNS servers should be allowed remains to be seen, as 
this would enhance complexity and raise security issues. The full 
protocol access doesn't even need to be publicly available.

For demanding, high security or very big customers, the solution is to 
field their own corporate VNS server, which may even have off-band 
(non-Internet based) connection to vendors' VNS servers with reliability 
or QoS guarantees. This extra service would be a new revenue stream 
opportunity for AV vendors.

I would like to repeat, that this is a kind of a minimalistic concept, one 
that allows reaching a uniform and industry-wide virus name for any 
malware probably some 24-36h after fist finding. Of course, during the 
first day, virus naming confusion and chaos may still rule. I'm not sure if 
the  proposed solution can solve the media FUD (a.k.a. CNN factor), 
which  problem was emphasized in the Toronto antivirus conference.

Thanks for your attention, Sincerely: Tamas Feher from Hungary.

(*)
Footnote: Sorry, this is not included in the posting to full-disclosure 
mailing list, because it is too weird for the public and/or could hurt some 
AV-vendors.



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ