On Fri, Dec 10, 2010 at 8:49 AM, David Woodhouse <[email protected]> wrote: > On Tue, 2010-12-07 at 23:59 +0200, Sergey Kononenko wrote: >> While investigating security break in the network of my company, I've >> captured (by tcpdump) sequence of successful remote root attack through >> Exim. It was Exim from Debian Lenny (exim4-daemon-light 4.69-9). > > Thanks Sergey for the notification, and the help in analysing it. > > There are two flaws here. The first is that the attacker managed to get > a remote shell running as the Exim user, and the second that they could > then escalate their privileges to become root. > > These have been assigned two separate CVE IDs: > > CVE-2010-4344 exim remote code execution flaw > CVE-2010-4345 exim privilege escalation > > ===== > > The first issue is caused by a string handling bug which was filed as > bug #787¹ and fixed in Exim 4.70, released in November 2009. > > The exploit seen in the wild is making use of the fact that the Exim > default configuration will log all headers of a rejected mail to the > rejectlog. By crafting a set of headers which will trigger the bug, the > attacker manages to overflow the log buffer and scribble on the memory > which contains the ACL for the 'MAIL FROM' command. When the attacker > follows up their rejected mail with another 'MAIL FROM' on the same > connection, the corrupted ACL is evaluated, and they obtain a shell from > the ${run...} directives they placed in it. > > The obvious solution to this problem if you're still using Exim 4.69 or > lower is to UPGRADE TO A CURRENT VERSION. If for some reason that is an > issue for you, then rebuild Exim with the patch² applied. > > A patched version of exim-4.69 for Debian Lenny is already available: > http://lists.debian.org/debian-security-announce/2010/msg00181.html > > In the *very* short term, if you can neither rebuild your own version > nor go offline while waiting for your vendor to ship a fixed > version, you can protect against the known exploit by using the > 'log_selector = -rejected_header' configuration option to disable Exim's > logging of headers when rejecting a message. However, this only protects > against the code path which is actively being exploited today; the > underlying string handling bug still exists and there may be other ways > for an attacker to craft strings which reach the affected function. It > is *NOT* a real fix for the issue, just a way to reduce your risk. > > Thanks to James E. Blair and Paul Fisher for reproducing this issue, > giving us a simple test case, and identifying the underlying bug. > > ===== > > The second issue is very simple. If Exim is built with the > ALT_CONFIG_ROOT_ONLY configuration option unset, which is the default, > then the privileged Exim user can invoke Exim with an arbitrary > configuration file, and ${run...} directives in that configuration file > will be executed as root. > > The simple fix is to ensure that your version of Exim is built with the > ALT_CONFIG_ROOT_ONLY option enabled, and note that this may result in a > loss of functionality in certain cases where more than one configuration > is in use. The 'exim' user will no longer be permitted to invoke Exim > with an alternative configuration file and have it executed with root > privileges. > > To cope with that loss of functionality, we are working on a way to > 'whitelist' alternative configuration files which *are* acceptable to be > run with root privileges. This is being tracked as bug 1044³. > > ===== > > Given that the remote flaw was fixed over a year ago and does not affect > current releases of Exim, and given the existence of the > ALT_CONFIG_ROOT_ONLY option to avoid the local privilege escalation, the > Exim team has decided that there is no immediate need to rush a new > release of Exim out the door. > > We plan to remove the ALT_CONFIG_ROOT_ONLY option (making the code > always behave as it currently does if that option is set), and then take > steps to restore the esoteric functionality that is lost by doing so, > and release a new version of Exim in good time. > > > -- > David Woodhouse Open Source Technology Centre > [email protected] Intel Corporation > > ¹ http://bugs.exim.org/show_bug.cgi?id=787 > ² http://git.exim.org/exim.git/commitdiff/24c929a2 > ³ http://bugs.exim.org/show_bug.cgi?id=1044 > > > > -- > ## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim > details at http://www.exim.org/ ## >
I believe Redhat ships a 4.6x version of Exim. I have a support contract with them if anyone believes it may be helpful to alert them about this issue and for them to distribute patched versions to Redhat customers. -- Brent Jones [email protected] -- ## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
