Cannot detect viruses

[Bart Bailey]

In Message-ID:<[email protected]> posted on Tue, 8 Jun

They should concentrate on compression algorithms as they relate
to runtime decompression executables so that such executables
can be scanned. A regular compressed or otherwise archived
program file does not present a threat until it is decompressed or
un-archived. Granted, there may be some need to prevent the
clueless from even getting the chance to execute the contained
malware, and automating the process would require some kind
of scanning within archives, but there is a way to attain this through
policy as well.

I believe there are discernable differences between packed executables
with a potential for trouble, and benign compressed archives, regardless
of what they contain.
Something to do with the [mx] header?

 

[Jason Wade]

It makes for an interesting problem for av software.
How is it going to check inside something like that?
(a password protected zip file)

KAV literally reads the password in the message portion of the email
and uses it to unzip and scan the files "within".
[ chomp ]

My esteem for KAV has just gone up a couple of notches!

 

[null]

In Message-ID:<[email protected]> posted on Tue, 8 Jun

They should concentrate on compression algorithms as they relate
to runtime decompression executables so that such executables
can be scanned. A regular compressed or otherwise archived
program file does not present a threat until it is decompressed or
un-archived. Granted, there may be some need to prevent the
clueless from even getting the chance to execute the contained
malware, and automating the process would require some kind
of scanning within archives, but there is a way to attain this through
policy as well.

I believe there are discernable differences between packed executables
with a potential for trouble, and benign compressed archives, regardless
of what they contain.
Something to do with the [mx] header?

Sure, there are quite discernable differences. The abilility of av to
handle on-demand a wide variety of packers and versions, and multiple
packing with different packers, is very important. IMO the ability to
decompress and scan "within" various archives is relatively
unimportant ... with the exception of sfx or self extracting files
(having a .EXE file extension). There is the zip sfx, for one example.

I suspect to some extent, scanning within archives became a
"oneupmanship" competition, with added pressure from independent
testing agencies which added this category and scored av products on
their ability to handle a variety of archive types.

I once had a brief private communication with a Sophos av researcher
who was concerned that some method might be found to auto-execute a
program while unzipping it. To my knowledge, this hasn't yet been
done. I've personally run a high risk from time to time by downloading
zipped malware from vxer sites and unzipping (or sometimes unraring).
So far so good

Point being that users should be safe decompressing archives, so far
as I know. So what's the big deal about the ability to scan "within"
zips and other archives? It seems like its mainly a marketing thing,
and users have simply become accustomed to the convenience.


Art
http://www.epix.net/~artnpeg

 

[FromTheRafters]

In Message-ID:<[email protected]> posted on Tue, 8 Jun

They should concentrate on compression algorithms as they relate
to runtime decompression executables so that such executables
can be scanned. A regular compressed or otherwise archived
program file does not present a threat until it is decompressed or
un-archived. Granted, there may be some need to prevent the
clueless from even getting the chance to execute the contained
malware, and automating the process would require some kind
of scanning within archives, but there is a way to attain this through
policy as well.

I believe there are discernable differences between packed executables
with a potential for trouble, and benign compressed archives, regardless
of what they contain.
Something to do with the [mx] header?

Yes, I think you may be referring to the MZ at the beginning of
executable programs. I think that that part is mostly now only to
run the code which displays that the program requires Windows
or "this program cannot be run in DOS mode" messages. I'm not
too sure that it is actually needed in any way now. I see PK at the
beginning of .zip files and most others I have seen have something
that identifies them as well. The point I was trying to make was that
the decompression algorithms for normal compression programs
(or some other tactic) might be useful for mailserver level scanners
to aid in the filtering of mass-mailer floods. The desktop applications
should only really need to apply this decompression technology to
the runtime unpackers using those algorithms.

 

[FromTheRafters]

In Message-ID:<[email protected]> posted on Tue, 8 Jun


Judging by the frequency of posts discussing issues with mail scanning
and subsequent disposition of suspect mail and/or its attackments, I'd
guess that more than a few rely on some windows based application to
perform concierge service in lieu of their own common sense.

I believe that it was the humorist known as "Mark Twain" that said
something to the effect that common sense is niether a sense, nor is
it at all common.

then come back here bitching about how;
"they told me *nix was imune to virii" ;-)

Well, you *could* say that there is no such thing as a *nix virii.
:O)

 

[FromTheRafters]

It makes for an interesting problem for av software.
How is it going to check inside something like that?
(a password protected zip file)

KAV literally reads the password in the message portion of the email
and uses it to unzip and scan the files "within".
[ chomp ]

My esteem for KAV has just gone up a couple of notches!

Unfortunately, worms then adapted the password in graphic approach.
Not insurmountable, but much harder to detect than they are to create.

 

[Bart Bailey]

In Message-ID:<[email protected]> posted on Tue, 8 Jun

The point I was trying to make was that
the decompression algorithms for normal compression programs
(or some other tactic) might be useful for mailserver level scanners
to aid in the filtering of mass-mailer floods.

Filter against the usual gang of culprits; HTML, Attachments, etc. and
you won't have to worry about the <10% of mail that's left.

 

[FromTheRafters]

In Message-ID:<[email protected]> posted on Tue, 8 Jun


Filter against the usual gang of culprits; HTML, Attachments, etc. and
you won't have to worry about the <10% of mail that's left.

That works for the end user, but it wouldn't work for the MTAs.
Unless you can get all of their clients to agree that HTML and file
attachments are *not* something that they want in their e-mail.

 

[Bart Bailey]

In Message-ID:<[email protected]> posted on Wed, 9 Jun

That works for the end user, but it wouldn't work for the MTAs.
Unless you can get all of their clients to agree that HTML and file
attachments are *not* something that they want in their e-mail.

Put it in the EULA, if you want to use our MTA, then don't expect us to
pass a bunch of crap for (or against) you.