[Avcheck] Mailbombs and the like: what can we do?

[Michael Tokarev]

[crossposted to avcheck and amavis lists]

I have a question for all of us that I fell needs some
attention -- at least I don't fell comfortable to make
a decision without some words from others...

The problem is: mailbombs and not mailbombs, and other
similar things.  I hope everyone knows about 42.zip
attack.  Antivirus software that runs on mail system
is a real target for such attacks.

There are some methods exists to eliminate or lower
possible damage -- like checking compression ratio,
setting quotas or limits for disk, memory and/or cpu
time, setting timeouts for one message, and the like --
i.e. setting some limits.

Well, ok, let's assume that we detected a situation
where some message will be over limit.  So a question:
what next?  This is not a simple question, at least
to me.

I remember last New Year (2001), when our customer
sent a picture to some of his friends, including
me.  Originally picture was grayscale gif file.
But that person opened it in MS Paint, edited a
bit, and saved in 32-bit truecolor .bmp file!
Original file was about 200K in size.  Now, new
edited variant was about 40M.  Mail system was
refused to accept such message, so he archived
it using zip and then sent...

I realize this is a stupid situation, and a stupid
person... ;)  But what the mailsystem should do with
such a file?  I just tried it with DrWeb -- both
of it's protection mechanisms was triggered --
MaxCompressionRatio and Timeout (both was set as
per default)...   AVP used some minutes to scan
this mail (on my 486 machine).

The same will happen with unreasonable deeply
archive structure (think about MIME message/rfc822
as about another sort of archive), and especially
(interestingly, how this will be handled by modern
antiviruses, after 42.zip  bomb?) --
  create file 42.test with 2Gb zeros
  zip -0 42_1.zip 42.test
  zip -0 42_2.zip 42_1.zip
  zip -0 42_3.zip 42_2.zip
  zip 42.zip 42_3.zip
Note that every 42_*.zip is about 2M in size!

I don't feel comfortable to refuse such a messages.
The message was accepted by a mail system, MTA not
said "5xx message too complex" or the like.
Refusing such (legal, in case it is really legal!)
message -- so how to really *use* the mail system,
at the end?  It wan't perform it's primary actions!
Hey, our mailsystem does NOT WORK -- why I pay you
money, guys?!  -- this is a real question I expect
to hear when my mailsystem will reject multimegabyte
word files with a lot of bmp files inside from
a chief of our customer...  And there will be no
way to send such a file using mail, at all, at least
for such non-computer man (use archive with password --
what is simpler?).

Well, archives with passwords and the like are also
of interest.

First, suppose multipart solid archives (like e.g.
rar (www.rarsoft.com) can produce).  There is no
way to extract non-first part of it without having
all previous parts.  It is easy to look into first
part, but not to any subsequent one.  So, let the
mail to come on?

The same with passworded archives, and especially
with encrypted messages like PGP or S/MIME.  Last
two are absolute killers for any sort of server-side
antivirus.

To make things worse, *alot* worse, people who knows
that them are protected by an antivirus (especially
non-technicians) takes far less attention to security
aspect -- hey, we have had paid for antivirus, what a
hell we need to "watch carefully" after that?!
And with PGP or S/MIME, when their MUA kindly displays
"secure" icon, their attention is even less than
before...

Yes, I know that those last questions have no real
answer...

And for the end, one another question around the topic.

Imagine that many mailservers have deployed some sort
of antivirus protection.  The question is: how to
deal with "virus bounces"?  I personally have no idea
what to do...

Some user used someone's computer to send a message
to his friend.  That computer was infected, and a virus
was attached to message.  Next, message was delivered
to friend's mailserver that has antivirus installed --
and it bounced it to first user's address.  Next,
those first user's mailserver also has an antivirus,
and bounce was not accepted, because it contains a
virus...

Next, all sorts of double-bounces (remeber: we should
deal with antivirus software, not with mail software.
As practice shows, antivirus people have little or no
clue about mailsystems...) and the like -- this might
be worse than virus attack itself!

Well, one can say -- simple do not bounce the message,
include only headers of it, and that's all.  But wait --
I sent you a message with important info (our mailsystem
is reliable, is it?!), so where that info now?  I know
it was infected, but I have a tool that can cure it
or extract what I need -- so where is my message?!  Give
me it back, sirs!

I thought about adding some headers, using dedicated
recipients that will NOT be excluded (i.e. them will
get even infected mails) and the like.  But wait --
I can place any header as I like into my message --
and thus bypass virus checking...  The only reasonable
solution is to use digitally-signed messages where
signers will be antivirus daemons -- but in this case,
we will need to set up some trusted relationship and
all the games around...

Well.......  May be things aren't so bad as I described
here?

Comments?

Regards,
 Michael.