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:
> 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
> David.Woodhouse@??? 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
brent@???
