From: Murray S. K. <ms...@se...> - 2009-01-07 20:05:36
|
This affects all versions from 2.5.0 to 2.7.2. With the addition of configuration reloads in 2.5.0, there is a failure to set up some configuration defaults in certain circumstances. This can lead to crashes when particular message mutations pass through the filter because of assertion failures or invalid pointer dereferences. Specifically, if you don't use "-C" on the command line and don't use any of the "On-" action directives in the configuration file (or don't use a configuration file at all), the default actions for those exceptions are never loaded. The action is to "continue" in those cases as a result, rather than the intended (documented) defaults. This means when libdkim rejects a message for formatting reasons, the filter will plunder forward, continuing to process the same message rather than halting processing as it should. This eventually causes the filter to make a call into the DKIM library which causes an illegal request or an assertion failure, and the filter will crash. The specific instance of this that has been observed is as follows: a) no use of "-C" on the command line b) no "On-*" directives in the configuration file (or no configuration file) c) a Sender: header with an address whose domain is in the list of domains to sign d) no From: header on the message A permanent fix has already been added to the impending 2.8.0 release. A patched beta release of it is already available. I expect to be posting that around the end of this week. In the interim, you can protect your installations from this by either: 1) starting your filter with "-C int=t" on the command line. The default includes "int=t" so this won't change your filter's operation, but it will cause the full set of defaults to be established properly as the filter starts up; OR 2) editing your configuration file to contain the line: On-InternalError tempfail ...which has the same effect. The upcoming release fixes the filter's default loading and also hardens the library so even without that fix (or without the filter), a crash will no longer result. If people want or need a patch to 2.7.2 while waiting for 2.8.0 or would rather do that than upgrade right away to a new release, I can produce a 2.7.3 or just post a source patch here. Please let me know if you have such requirements. |
From: Scott K. <iet...@ki...> - 2009-01-07 20:53:51
|
On Wednesday 07 January 2009 15:05, Murray S. Kucherawy wrote: > This affects all versions from 2.5.0 to 2.7.2. ... > If people want or need a patch to 2.7.2 while waiting for 2.8.0 or would > rather do that than upgrade right away to a new release, I can produce a > 2.7.3 or just post a source patch here. Please let me know if you have > such requirements. This affects two Ubuntu versions that are post-release and I'll have to patch if I am to fix them, so a patch would be handy. It's 2.5.4 and 2.6.0 if it matters. Scott K |
From: Murray S. K. <ms...@se...> - 2009-01-07 21:01:35
Attachments:
PATCH-2-5-4
PATCH-2-6-0
|
On Wed, 7 Jan 2009, Scott Kitterman wrote: > This affects two Ubuntu versions that are post-release and I'll have to > patch if I am to fix them, so a patch would be handy. It's 2.5.4 and > 2.6.0 if it matters. Diffs to those two versions attached. They're identical except for the line numbers and version numbers. |
From: Murray S. K. <ms...@se...> - 2009-01-07 21:04:39
|
On Wed, 7 Jan 2009, Murray S. Kucherawy wrote: > The specific instance of this that has been observed is as follows: > > a) no use of "-C" on the command line > b) no "On-*" directives in the configuration file (or no configuration file) > c) a Sender: header with an address whose domain is in the list of domains > to sign > d) no From: header on the message Forgot one: e) all other signing criteria are met (MTA name matches, macros match, source is on the "internal" list, etc.) That is, one cannot craft a message from outside and send it inbound and expect the filter to crash, i.e. it's not exploitable from outside. |