Re: Re: Question about Viruses

[Drsolly <drsollyp () drsolly com>]

On Fri, 7 Jul 2006, Peter Kosinar wrote:

> [Mixing two or more threads is not a good idea, I know...]
>
> Hello,
>
> > > In fact, this happens regularly (though, not very often) -- certain pieces
> > > of malware tend to be infected by parasitic viruses (Win32/Parite.B comes
> > > into mind) and are thus detected as such and possibly disinfected by the
> > > AV and the underlying piece of malware might remain undetected. On the
> >
> > It would be a *remarkably* crappy AV that behaved that way. What Findvirus
> > did (and I guess still does) is, if it's told to do a repair, then it
> > strips off the virus to get back to the underlying file. Then it checks
> > that for viruses - if it finds a virus, it does a repair ... and so on,
> > down to an unlimited number of times (as long as there's still a virus in
> > the file).
>
> You're right, naturally, but I had a different scenario in mind -- a new 
> (i.e. not-detected-yet) malicious program infected by a well-known 
> parasitic virus. The AV would pick and clean the virus and the trojan 
> won't get detected (well, what a surprise).
>
> While this may seem equivalent to just receiving the new trojan without 
> the infection, it -is- different from psychological point of view. In the 
> first (infected) case, the user can get more angry about the AV he's 
> using; after all, it SAID "The file br1tn3y_n4k3d.exe has been cleaned 
> successfully"! In the second case, the AV wouldn't say anything (which AV 
> does report every clean file it scans? :-) ), so the user wouldn't blame 
> it so much.

So, what you're saying is that scanner AV's won't detect new malware. I 
agree.

But I'm not really seeing that the situation is worse when the new malware 
is also infected by a file virus.

And anyway, if you have the AV set to delete the infected file, then the 
trojan is gone also.
 
> > > Couldn't the AV simply block the access to other files during the
> > > scanning/cleaning?
> >
> > No need, each time a file is opened by the operating system, the virus
> > scanner is invoked to check the file first. So, if you open a second file
> > while the first file is being scannedd, you'll have two instances of the
> > virus checker active. If you open a third, ... and so on.
>
> Depending on the scanning speed and the amount of advanced features (like, 
> virtual machine emulation, etc.) your AV supports, this can lead to 
> resource (memory/CPU) starvation quite quickly (and it'd also be pretty 
> easy to trigger).

Again, that depends on how the code is written. And it might not be easy 
to trigger the condition.

> > > It depends on the AV (for example, some AVs might have different "levels
> > > of confidence" of signatures; so that a signature with higher level
> > > overrules the result with lower level).
> >
> > Findvirus would detect the last infection, and report that. So, if a file
> > were infected by Jerusalem virus and then Vacsina, it would report
> > Vacsina.
>
> This is true for simple parasitic viruses. What would you do if you had a 
> file infected by two different EPO's? 

What's an "EPO"?

> Or, what about a trojan (i.e. 
> non-parasitic piece of malware) which got infected by a standard parasitic 
> virus? Which name would it get reported as?

Findvirus would always report the outermost thing, so it would report the 
standard parasitic virus. I'd guess that most other AVs would do the same.

> > > On the other hand, the question in
> > > most cases reads "Is the file dangerous?" instead of "Which particular
> > > breed of malware is it?", so it might be a bit irrelevant.
> >
> > If you're going to do a repair, you *must* do an exact identification 
> > first. If you're going to delete, then it makes some sense not to do an 
> > exact identification.
>
> Yes, this is true; I described it from the user's point of view, not from 
> the AV's -- as long as you can clean the file (i.e. it's infected by a 
> parasitic virus), you have no reason to care about the name reported to 
> the user because after cleaning one of culprits, the other one will get 
> reported (and possibly cleaned) as well. AV naturally needs to know the 
> "outermost" piece of code it needs to remove (though, the double-EPO 
> mentioned above still remains a problem; one can probably only hope that 
> the cleaning routines are commute in such case).

I still don't know what an EPO is, but for parasitic viruses, the repair 
is commutative (by which I mean, the orer of infection doesn't affect that 
ability of the AV to do a full repair). 
 
> > > I never noticed such a war - maybe the marketroids did that. Certainly,
> > > Findvirus, when you run it, tells you how many things it's scanning for.
> > > That seemed like something people would like to know. But I notice that
> > > the figure is up to 200,000 now.
>
> If two viruses differ only in the message they display, are they the same 
> virus or two different ones? 

I'd probably classify that as two variants of one virus.

> If they differ only in the activation date, 
> are they the same?

Ditto.

> If they were compiled using two different compilers 
> (think, HLL malware seen nowadays), are they the same piece of malware or 
> two different ones? 

Probably the same, but two variants.

> How much do they need to differ to deserve two 
> different names (and thus at least two different signatures?)

That's actually fairly subjective, and partly depends on how your AV works 
(they don't all work the same way). AV folks have (well, used to have, I'd 
guess still do) long arguments over beer at AV conferences about this sort 
of thing, and of course there's no definitive answer.

I had a list of several dozen Jerusalem viruses, and it's an interesting 
question about how far from the original can a variant be, and still be 
classifiable as a Jerusalem variant. There's no one answer to that 
question. 

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