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
