On Mon, 28 Jan 2002, Mark Morley wrote:
> A while back we noticed Exim processes that were going nuts, consuming
> all available RAM and swap space and eventually dying.
>
> We narrowed it down to a filter issue, and we've been able to reliably
> reproduce it now. This could be used as a form of DOS attack.
There was a similar report recently.
> If you inject a message into the system that contains a HUGE number of
> headers, the filter processing routines seem to go into some sort of
> endless loop, continuously allocating more and more RAM.
The case I saw before was using $message_headers in the filter file. I
have fixed this in Exim 4 by restricting the length of $message_headers
to 64K.
> We've seen this happen on a number of occasions now with spam containing
> as many as 1,500 "Apparently-to:" headers.
>
> The actual content of the filter doesn't seem to matter that much.
It should. Does it refer to $message_headers or to $h_apparently-to:?
> The process dealing with the message rapidly consumes all available RAM
> and the server begins to swap. This drives the load up considerably.
> Eventually malloc() fails (you'll see malloc errors in the panic log)
> and the process dies.
That does look exactly like the $message_headers problem.
> I discussed it with Philip and he's going to put some sort of limit on
> headers in the next version.
Ah! I'd forgotten it was you. :-)
> But the question is, does anyone have any ideas about how to prevent this
> kind of thing now, with the current version of Exim?
I'm about to release the next pre-release of Exim 4 (tomorrow). Any
competent programmer (grin) should be able to retro-fit the changes in
the expand.c module to Exim 3. They are pretty localized.
Philip
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
