Re: [exim-dev] Remote root vulnerability in Exim

Top Page

Reply to this message
Author: Brent Jones
To: David Woodhouse
CC: exim-dev, pkg-exim4-maintainers, Sergey Kononenko
Subject: Re: [exim-dev] Remote root vulnerability in Exim
On Fri, Dec 10, 2010 at 8:49 AM, David Woodhouse <dwmw2@???> 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:
> 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
> David.Woodhouse@???                              Intel Corporation
> ¹
> ²
> ³
> --
> ## List details at Exim details at ##

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

Brent Jones