On 2011-06-09 at 09:36 -0700, Todd Lyons wrote: > On Thu, Jun 9, 2011 at 9:25 AM, Patrick Boutilier <[email protected]> > 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 -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
