[Avcheck] Re: [AMaViS-user] Mailbombs and the like: what can we do?

[Lars Hecking]

 Michael,

 That's a very long post, but at least it comes in digestable chunks
 this time ;-))

 Not sure I can answer all of it, but you have certainly identified
 some issues that we don't necessarily have a solution for yet.

Michael Tokarev writes:
> [crossposted to avcheck and amavis lists]

[...]
> 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.

 I have added something like this into amavis-cvs on July 16. The code
 checks whether the ratio of [files at current decompression level] and
 [files at previous decompression level] exceeds a given treshold (magic
 number alert) twice. The only release version with this code is
 amavisd-snapshot-20010714.

 Ricardo Ferreira has contributed a patch which uses a different method
 (actually checks disk space and sets resource limits), but I haven't
 decided yet whether to put this into cvs. The patch is available at
 http://www.amavis.org/contrib/.

 My code is tested against 42.zip (as one, special case), and I imagine
 Ricardo's is, too.

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

 The code in the current amavisd snapshot simply issues EX_TEMPFAIL
 and logs "Possible DoS detected - requeue". This method relies on
 admins to monitor their logs.

 Ricardo's code, I think, quarantines the offending mail message and
 notifies the admin.

> The same will happen with unreasonable deeply
> archive structure (think about MIME message/rfc822
> as about another sort of archive), and especially

 I once had a case where someone sent and entire 35MB mailbox as attachments.
 Only got noticed because load on the mail server was consistently high for
 a long period of time. I finally stopped the mail system and delivered the
 mail manually (it was local -> local).

> (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.
[...]

 I do. I set the policy, and I define what constitutes abuse.

> 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?
 
 That's correct, and we already ran into a bug in the Archive-Tar
 perl module in relation to multivolume tar files. We currently
 handle this by treating such a part as "atomic" (i.e. cannot
 be decoded/unpacked further) and feeding it to the virus scanner.

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

 Why? Encryption offers a convenient way for people to send me
 infected email for analysis ;-)

 The real problem, and you may check the recent discussion on bugtraq
 about the PDF virus, is whether the recipient's client does things
 automatically without manual intervention. If you have to manually go
 in and decrypt or reassemble, you should know what you're doing.

 Virus protection can never be 100%. But software like ours can at least
 take out the majority of threats. (you cannot have 100% security. but
 you can configure your system so that it's much harder to break in. that'll
 keep the script kiddies out.)

> 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...
 
 Good point. That's an experience I haven't made yet.

[...]
> 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...

 Around here, we use postfix. By default, the size of bounce
 messages is limited to 50k. So they just get cut off.

> 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!

 How very true. The flood of AV notification messages on Usenet
 and mailing lists recently was enourmous (SirCam ...). When I
 complained to the contact addresses given and explained in detail
 what was wrong, it usually went like: "I have to get back to the vendor."
 Later: "No, they don't support this configuration."

> 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!

 Amavis sends only the headers and, if so configured, quarantines
 a copy of the original mail. Admin and intended recipient(s) get
 the id of the quarantined message.

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

 Yeah, these approaches are incomplete, and bound to fail sooner
 or later.