TNEF problem

[S.R.Patterson]

Quoting Julian Field <jkf at ECS.SOTON.AC.UK>:

> If you could up the limit to 100Mbytes (enough for most sites), and pass
> it on to me, I will happily put it in the standard MailScanner
> distribution until you get a new version from the original author.

Will do, in fact if I might be able to kludge it a bit more and add a command
line parameter or at very least a #define.  I'll pass you a diff and compiled
versions for solaris and linux (based on redhat 6.2 probably) once I've done so.

> Also, is the problem actually that it runs out of memory, or that it
> takes a very long time to run (or both)?

I imagine both - so far, owing to huge amounts of swap on our mail servers,
we've noticed the delay in email before we've run out of memory and killed it
off ourselves (or it's not used all of the 10G or so available before exiting
normally!)  Of course in the mean time things swap like crazy (which is where a
lot of the load originates I'm sure).

> If it could be killed after running for,
> say, 2 minutes, then the same DoS attack prevention mechanism I am
> intending to write for Sophos could be wrapped round the tnef decoder as
> well.

Yes, that would work quite nicely so long as everyone has enough memory/swap
available that it won't be exhausted within 2 minutes.  From what I can
understand the situation with the current TNEF is it claims that one of the
attachments is made up of 750 000 000+ "blocks" of a smallish amount of memory,
but I think it could be feasible for the header to instead claim a small number
of "blocks" each of a very large amount of memory and this situation may cause
your swap to get eaten up a lot more quickly.

My kludge is, briefly, to check:

1 - is the number of "blocks" for this "attachment" greated than 20M?  If so,
we'll assume that none of the blocks would be zero size and hence that the
attachment will exceed 20M and so we'll exit without malloc()ing at all.

2 - Otherwise for each block malloc() the claimed block size and keep a running
tally.  As soon as this tally exceeds 20M abort.

This way there's a good chance nastiness will be caught by the first method and
tnef will quit pretty quickly.  The second test is obviously slower and allows
usage of probably 20-30M (there's some overheads) before quitting.  That's just
based upon my understanding, I've not had a chance to do any intensive sizing
tests.

Finally it's VERY worthey of note that since this method aborts without
unpacking the attachment there is no guarantee that viruses won't get through
inside tnef type attachments.  If you're worried perhaps you (Jules) can check
on the return code of tnef and if it's -1 (failure) then you reject the
attachment as "Unexpandable archive, rejected" or something?  Or do you already
do this?

Steve