Re: Multiple AV Vendors ignoring tar.gz archives

[James Eaton-Lee <james.mailing () gmail com>]

In the majority of businesses, firewalling and virus protection are done
at the border of the network for a reason; when you eliminate as many
viruses and malicious network traffic in one place at the edge of your
network first, you effectively segregate 'good' and 'bad' information,
and provide business accountability into the bargain. 

It is for precisely this reason that 99% of businesses have some sort of
firewall (even if it's only a NAT gateway) on the *EDGE* of their
network, at the internet point of presence, rather than having client
firewall software installed on every client PC. Although you'd be
hard-pressed to find a business without client antivirus software on
every machine (if only for the simple reason that you can't protect
floppy disks with a firewall), you can get away with not scanning
e-mails on a client machine. 

Add to this the simple fact that it is difficult to manage and account
for client anti-virus software - client machines are to an extent
unmanaged and an 'unknown quantity' whereas servers can be *very*
tightly locked down, assuring a far higher degree of reliability from
server-based virus-scanning tools, firewalling, and intrusion detection
than client machines which are vulnerable to a wide range of attacks and
problems. Server anti-virus software starts to become more and more
attractive at this point..

..add to this the behaviour of different e-mail clients; especially in
environments which are not based on a single platform, there can be many
e-mail clients run in a business, and not all of them will interact with
anti-virus software in the same way. Linux clients may not be running
antivirus software at all, and yet in the case of .tar.gz and .tar.bz2
archives, are most likely to be exposed to marginally more 'exotic'
antivirus formats. 

Bearing all of these factors in mind, and also factoring the growing
reliability of SMEs on third-party and centralised antivirus scanning
for their mail (from external service providers via MX routing, and via
e-mail servers which aren't exchange which incorporate antivirus
scanning simply by calling the antivirus software on the server itself),
and gateway scanning becomes more and more significant; possibly more so
than desktop software for mail - mail being the most common form of
virus transmission - so significant that this *is*, in fact, a serious
problem.

I also disagree with you that it's a non sequitur to say that anti-virus
writers would be slow to react to viruses transmitted inside archives
they could not scan; all that an antivirus package is - essentially - is
a daemon doing pattern matching on all data coming into and out of
machines; anti-virus definitions (patterns) are very easy to write and
require little work to push to customers of anti-virus writers; archive
scanning, however, is a *functional* difference in the way in which
antivirus software works, which carries numerous implications; updating
an antivirus scanner's scanning engine is quite different to updating
the definitions. 

Add to this the fact that implementing archive support in an antivirus
package isn't as simple as it might seem; although bz2 is released under
a BSD license, gzip isn't - it's GPL, and therefore any antivirus vendor
would have to write their gzip code totally from scratch. There could
certainly be enough of a curfuffle surrounding a virus using one of
these archive formats to cause a delay of a few hours or even days in
releasing updates for antivirus software which addressed the issue - and
as we all know, the major damage in any virus epidemic is done in a very
short space of time. 

To be honest, though, that isn't really the point. antivirus vendors
necessarily have to write antivirus definitions reactively - but there's
nothing other than sheer laziness which is preventing them from
*pro*actively incorporating support for these types of archives into
their software.

regards,

 - James.

On Sun, 2005-02-06 at 11:15 +1300, Nick FitzGerald wrote:
Barrie Dempster wrote:
> > By passing some archives through www.virustotal.com I discovered
that
> > some AV companies ignore tar.gz's and possibly other archive formats
> > that aren't very common on windows systems (but supported by the
common
> > archive tools). 
> >
> > If virus writers start using these formats AV companies could be
slow to
> > react as in some cases they may have to write functionality into
their
> > products that doesn't currently exist (support for scanning inside
said
> > archives) this could delay signature updates.
>
> That's a non sequitur.
>
> If a virus was released that depended on, say tar.gz archives, and
some 
> AV products did not have tar.gz unpacking capabilities, there would
be 
> no hindrance to those companies releasing detection updates.
Afterall, 
> what they detect are the unpacked contents of such archives, so 
> detection of the actual malware is just as easily added and shipped 
> regardless of whether the malware in question self-packs
in .RAR, .ZIP, 
> .TAR.GZ or .ZOO format (or does not pack itself in any archive format 
> at all...).
>
> Worse however, is the implication that missing unpacking abilities
for 
> some modestly common archive type is a terrible flaw in a scanner.
>
> Well, OK -- in a gateway scanner it is likely to be a terrible flaw.  
> Any vaguely competent gateway scanner should have basic knowledge of 
> all archive formats and should have an option to quarantine all 
> messages with archives in the formats it cannot unpack and inspect.  
> Sadly, most gateway scanners are not designed this way.  It is the
job 
> of a gateway scanner to not let anything "dangerous" in and if you 
> cannot tell what something is, prudence says you keep it out, or at 
> least set it aside for more expert inspection.
>
> However, once something gets to the desktop, it is only very mildly 
> inconvenient that a scanner does not know how to unpack, say, tar.gz 
> archives.  The point of a desktop scanner is to stop as much as 
> possible that has got to where it shouldn't be.  Known virus scanning 
> is a far from perfect method for achieving this, but as the only 
> intelligent method of achieving it has been entirely disregarded by 
> users, AV and OS developers, scanning is pretty much what we are left 
> with.  Anyway, as we are assuming that the malware in question can be 
> detected already, let's look at the consequence of a desktop scanner 
> not knowing anything about tar.gz packing and the arrival of a piece
of 
> known malware in such an archive...
>
> Let's assume that the user has a tar.gz handler and the user double-
> clicks on the dodgy Email attachment in question (the attachment that 
> the shoddy gateway Email scanner should have stopped, even if it 
> couldn't scan inside tar.gz files because this is hardly a
just-minted 
> compression format...).  What happens?  The on-access virus scanner 
> says nothing as the tar.gz file hits the disk in some temp dir, as it 
> doesn't know anything about tar.gz archives.  For the same reason the 
> on-access scanner says nothing when the user's archive-handling
program 
> opens the tar.gz file from its temp dir.  As no code has so far been 
> deposited on the machine in executable form, this is not any kind of 
> failure on the part of the desktop scanner.  (Yes, some lily-livered, 
> weak-kneed sops may _prefer_ the "reassurance" of the malware code 
> inside such files being detected "as soon as possible" but that is
not 
> a strong (or even useful) criterion for judging a desktop scanner's 
> quality.)
>
> The user now sees, listed in the contents of the archive as displayed 
> by their tar.gz archive handler the "card" or "picture" or "document" 
> or whatever that the Email message promised, so double-clicks it.
_Now_ 
> their virus scanner gets excited.  The archive handling program 
> extracts the file to a temp dir and the on-access scanner (if set to 
> scan on writes and/or closes) detects the malware and pops an alert 
> (and blocks further access to the file or automatically quarantines/ 
> deletes/etc as it is configured).  If the scanner is only set to scan 
> on execute it will pop an alert (and block/quarantine/delete) a
moment 
> later when the archive handler tries to have the file executed.
>
> There is no failure here.  The desktop scanner "protected" the user,
as 
> designed.
>
> Yes, it is easy for testers to add tests such as "detects malware 
> packed in .ZIP files", "detects malware packed in .RAR files",
"detects 
> malware packed in .TAR.GZ files" but the results of such tests tell
you 
> squat about the quality of the product.  (In fact, that's not true -- 
> as it seems axiomatic that the larger and more complex a software 
> project the more bugs it will have, it would seem that the more
archive 
> formats a scanner can handle the buggier the scanner will be, so
maybe 
> such tests do tell us something about the quality of the products -- 
> the higher the score, the buggier the product will be...)

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html