(resent since the first attempt seems it got lost)
Hi David,
thanks a lot for this very informative report!
On 12/10/2010 05:49 PM, David Woodhouse 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.
We have a 4.69 custom installation, so I tried to replicate the exploit
at [1] but without success (FSVO it ;).
[1]
http://seclists.org/fulldisclosure/2010/Dec/222
we have set 'message_size_limit = 100M' and the attack stops with a
552 Message size exceeds maximum permitted
and log entry:
2010-12-13 11:50:06 [22328] 1PS5yL-0005o8-R7 rejected from
<root@???> H=(abcde.com) [195.110.97.5]: message too big:
read=105155021 max=104857600
is this mean that the attack needs to send more than 100M of data and so
our config is "safe"?
> 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³.
If some unlucky guy is in a position that cannot check how a given exim
installation was compiled, is there a way to know if
ALT_CONFIG_ROOT_ONLY was set or not at build time?
Thanks a lot in advance,
--
Sandro Tosi
Product Engineer
Linux based Solutions
Hosting Products
R&D | Dada.pro
sandro.tosi@???
