Re: [exim] Numerous segfaults with 64 bit exim

On 2011-06-09 at 09:36 -0700, Todd Lyons wrote:
> On Thu, Jun 9, 2011 at 9:25 AM, Patrick Boutilier <boutilpj@???> wrote:
> > Didn't try removing the quotes but did come up with a solution. I believe
> > that the messages causing segfaults were probably due to the length of
> > $spam_report . So I changed SA to produce a shorter, one line report. Not a
> > single segfault since.
>
> Ouch, that's likely another security release coming up. Hopefully the
> gurus can track down the offending code.

I do not believe that this is an exploitable security issue, beyond the
potential for DoS by knocking out an Exim process.

The null pointer comes from expand_string() failing; a debug run would
have shown the expansion failure. Using "control = debug" in an ACL to
apply to connections likely to trigger this would be one way to
selectively log the necessary lines, or just run a debug instance of
Exim.

So the NULL has been deliberately placed in as a return value, rather
than happening because of any kind of overflow/etc.

Note that the *default* message for the ratelimit response contains
newlines, so it's not the newlines that are the issue; I suspect that
the SA code to get $spam_report is somehow failing.

The text buffers for $spam_report are 32600 bytes long; overflows are
avoided; the socket used for talking to spamd is closed after the
communications, so anything over 32600 is just discarded.

Various errors reading and/or parsing the spamd response result in
LOG_PANIC messages; does paniclog exist? It's created on-demand, and
one good strategy is to delete it after you've dealt with whatever
caused it to be created, so that presence of a paniclog is a noteworthy
event.

At present, the only change I see to make is to ensure that the
ratelimit default message is used when expansion failed. We'll still
need more to go on, otherwise.

-Phil