Re: another VX site?

[Nick FitzGerald <nick () virus-l demon co uk>]

dudevanwinkle () gmail com to Drsolly:

> > Pretty easy, actually. We already agreed a naming scheme that's a bit
> > like
> >
> > the scientific system for naming flora and fauna, where the problem is 
> > much bigger. Read the Caro naming document. Google caro naming.
> >  
> Ja, but it seems in Caro there were (what are apparently now) some
> outdated assumptions, for example:
>
> Family_Name.Group_Name.Major_Variant.Minor_Variant[:Modifier] maybe
> should be updated to a few different standards that share the same type
> format (eg
> 1:OS_Name.OS_Version.App_Name.App_Version.File_Name.File_Version
> 2:Some_Name.Some_Version.Other_Name.Other_version, etc., format just
> like ip became ipv6 due to increased demand, Caro (and CVE,CME, etc)
> needs to be re-evaluated, updated, and fine tuned, just like any system
> that is worth keeping.

If you want to talk about _the_ CARO naming scheme, I'd suggest that 
you look at the _actual_ scheme, as it is (supopsed to be) used today:

   http://www.people.frisk-software.com/~bontchev/papers/naming.html

If you don't understand something, or think you have found an error, 
shortcoming or contradiction, please ask about it as the odds are that 
you don't understand something about the malware class/featrues/ 
functionality that naming scheme element is designed to deal with.  If 
you have found a genuine error, we'll be pleased to fix either the 
scheme or the documentation.

>   "All overwriting viruses written in a high-level programming
>    language are grouped in a single family, called HLLO. "
>
> Arent most of the 65k viri* written with a high level programming
> language? we could have something like
> OS_Name.OS_Version.App_Name.App_Version.File_Name.File_Version, but
> should also try and guess what the viri of the future will look like,
> and plan for a naming standard that has room for growth and could be
> added on to as the needs arise (eg: Encryption_Family.Encryption_Type or
> Polymorphic_Some.Polymorphic_Thing :-)

The problem with looking at what was really the first draft of a 
suggestion for the CARO naming scheme is that you can easily find 
poorly worded or outdated things.  This is an example -- what is not 
explained here is that, at the time the whole scheme was (initially) 
primarily concerned with DOS viruses as they made up the vast bulk of 
all viruses in 1991.  The "platform" name component was added later.  
Later revisions of the scheme, _VERY, VERY FEW OF WHICH_ were ever 
(publicly) documented fixed most of these _OR_, as the document was 
intended only/primarily for "internal to AV" use were moot because of 
obvious contextual knowledge common to those using or interested in the 
naming scheme.  As only professional virus (later "malware") analysts 
actually get to name malware, this contextual knowledge expectation/ 
requirement is not terribly problematic.

> > Ah, you've spotted the familial-type naming system, whereby all the 
> > malware that's very similar to Sober is called Sober.something, which 
> > makes the naming system possible. 
> >  
> well I can call everything "bob", but thats not much of a naming system.
> If I remember correctly, the current scourge is just different revisions
> of an open source malware app that has been modified to escape detection
> by AV companies, then "rediscovered". These apps have been modified by
> using a hex editor to cut the files in half, then scanned to see which
> half sets off detection, then cutting again, etc, etc. down to the part
> that makes up the signature, the that is the code that is changed (plus
> a slightly different payload). I know I am being very general, but it
> seems the method of detection put forth by av companies is what makes
> 3,000 variants of the same viri possible.  ...

No -- the methods used by any given current, real-world, practical AV 
is equally amenable to relatively simple (depending on your level of 
skill, I guess...) sample tweaking to make "trivial" new undetectible 
variants.  However, most of those trivial new variants will still be 
detected generically by some/many/most of the _other_ AVs that the 
malware writer did not target.

> ...  I like the detection method
> that NOD32 has, with variants being based on err, well I dont really
> know, but it sure catches a lot.

Hmmmm -- so NOD32 _does_ (mostly) detect such trivial variants, so 
presumably, if we extend your logic, that means NOD32 is NOT an AV 
product?  I guess that will surprise the boys back in the Slovak 
Republic...    8-)

And let me clarify something else -- are you saying that a file 
deliberately made to be program logic and binary-different from another 
SHOULD NOT be considered a different variant from the first file?

Some beetle species are separated _solely_ on the basis of things such 
as "has three hairs on the second segment of the third legs" vs. "has 
four hairs on the second segment of the third legs".  Perhaps that is 
wrong too?

...

Of course, whether an AV product _need_ detect, or need deetct _and 
inform the user_, of the precise variant when, despite the malwares' 
program logic and/or expression differences, their _effective 
behaviour_ is the same, is another question.  AV uber-purists have 
(mostly) always aimed for "exact identification" whereas others have 
tended to go for "if the functionality is about the same such that 
disinfection is the same we need not be too fussy about identifying 
precise variants" and a few have always been so sloppy that it matters 
not what they call something as half its detects are guaranteed to be 
entirely unrelated and some/many not even malware (for example, some AV 
-- I forget which offhand -- has a generic "unwanted file" or similar 
detection for _any file_ it does not have more precise identification 
of that is packed with FSG).

> > To calculate an md5, you have to specify which bytes you're going to
> > include in the summation. If you think about viruses, for example, you'll
> > recollect that each instance of a virus-infected file, will have bytes in
> > the virus part that are variable, and depend on the conditions of the
> > computer at the moment of infection.
> Hmm, I was assuming that a virus is based on a file somewhere, that has
> exploit code, ...

The state of virality, per se, has NOTHING to do with exploit use.  A 
virus _may_ use an exploit or three, just a text editor might include a 
grammar checker.  Just as a grammar checker is not a necessary part of 
a text editor, so vulnerability exploitation is not a necessary part of 
a virus.

> ... a payload, ...

Viruses need not have payloads.  They may, but just as a grammar 
checker is not a necessary part of a text editor...

> ... and a propagation method.  ...

Viruses need not have a propagation method.  Stoned is a virus and it 
has no propagation method.  Humans "propagated" it all round the globe 
by (unknowingly) carrying Stoned-infected diskettes and occasionally 
(and often accidentally) (re)booting a system with them, but the virus 
had nothing directly to do with this propagation.

_ALL_ a (practical/real-world) computer virus must have is recursively 
self-replicating code.

> > By the way, there's no such word as "viri", and people who refer to "viri" 
> > put themselves firmly in a group that you possibly don't want to be seen 
> > as being a member of.
> >  
> Just called my sisters wife, ...

It's not germane to this conversation, but I was not aware lesbian 
marriage was possible/legal anywhere in the US...

> ... who is a PhD in english on a tenure track
> at a college in Washington DC...  

Odd -- all the tenured English and Latin/Classics professors I've asked 
about this, or read their scholarly opinions of this, have all 
disagreed with your sister's wife...

> ...  she said "viri" was correct english, if
> new english. English needs updating on occasion too. so there :-)

Remind me not to do an English degree at that college....

"Virus" has been drafted into the English language _as a new word_ -- 
i.e. we took a Latin word and gave it an entirely (well, almost 
entirely) new meaning and use -- a meaning and use for which Latin (and 
ALL OTHER THEN EXTANT LANGUAGES) _had no word_ because it was an 
entirely newly discovered "thing" that was being named.

As such, "virus" as we use it to mean a biological or computer virus 
_is an English word_.  Thus, the rules of _English_ pluralization apply 
and the correct English plural of "virus" CAN ONLY BE "viruses".

It really is that simple.

Anyone who tells you anything different is either pulling your leg or 
talking through a hole through which something other than words are 
normally ushered into the world...

There are not a great deal of other examples, but there are a few.

So, that is the first flaw in "viri" and/or "virii" and/or "vira" being 
the plural of "virus" positions.

I'm sure the rest of the reasons have been bashed to bits by now, but 
as I've been writing this rather than reading the new posts...

"virus" in Latin _has no plural_ -- it is something like a mass noun -- 
for the Wikipedia-ites:

   http://en.wikipedia.org/wiki/Mass_noun

such as "air", as in "the air that I breath".  I know you can pluralize 
_other_ uses of "air" ("airs and graces" for example), but in the above 
usage "air" is a mass noun and as such unpluralizable (is that even a 
word?). Somewhat oddly the Wikipedia entry on the "plural of virus":

   http://en.wikipedia.org/wiki/Plural_of_virus

does not make this specific point quite as strongly as it could/should, 
and there is no link to Wikipedia's mass noun entry...

The Wikipedia "plural of virus" entry deals with the rest of the 
bogosity of "vira", "viri" and "virii" showing it to be the pseudo-
scholastic nonsense it is, so I'll not bother spelling it all out again 
after all.


Regards,

Nick FitzGerald

_______________________________________________
Fun and Misc security discussion for OT posts.
https://linuxbox.org/cgi-bin/mailman/listinfo/funsec
Note: funsec is a public and open mailing list.