"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). I
didn't find email of current maintainer of Exim, so I've decided to
write to this mailing lists. I don't want to publish all details of
attack before developers can investigate and fix vulnerability."
I haven't reproduced the buffer overflow since there is not actual info about it, but the local privilege escalation definitely works.
Later in the thread, one of the Exim devs recommends assorted mitigation strategies:
For my own machine, I've gone for the ALT_CONFIG_ROOT_ONLY=yes approach (one addendum to the ebuild and a recompile). This does not fix the (apparent) buffer overflow, but the escalation from UID mail to UID 0.
I'm not in a position where I can fix the ebuild right now, but if you just need to add this define, you have my permissions to add it, and bump if necessary.
I've committed 4.72-r1 (which is stable on all supported archs) with a fix.
From the last (public) comment from the upstream, it appears that they are working on it:
This was fixed in 4.70, but got no big attention until now:
Can someone please create a GLSA for this, as I dont know how to do that!? =)
Independent of this issue I think we should keep my fix in - or its slightly different "only known prefixes" variant. I'm not quite sure which one would be less disruptive if you actually run exim -C as a normal user regularly.
The fix in 4.72-r1 breaks existing installations where exim is run with non-default configuration file name. Upon starting the daemon it drops root privileges. When it spawns e.g. a queue runner it launches exim with "-C /etc/exim/something.conf". The ALT_PREFIX_ROOT_ONLY option causes the queue runner to drop root privileges immediately (since it was forked from a non-root process) and therefore it cannot deliver mails into user directories any more.
A - in my eyes - much better option is to set ALT_CONFIG_PREFIX to /etc/exim. Non-root users are not allowed to write there and even more complicated setups (such as ours) are still using this directory for different config files.
(In reply to comment #6)
> A - in my eyes - much better option is to set ALT_CONFIG_PREFIX to /etc/exim.
> Non-root users are not allowed to write there and even more complicated setups
> (such as ours) are still using this directory for different config files.
As I said: I'm on the fence on the issue since both solutions work for me. That said, we should /definitely/ implement one of them. I'd leave it to the GEntoo exim maintainers to decide, unless this is causing massive breakage.
The buffer overflow itself has been fixed ages ago upstream, so one could always fall back to 4.72-r0 for now.
version 4.70 and lower have been removed from the tree at Dec 11, 2010.
@security please close this bug
Exim 4.72 and earlier allows local users to gain privileges by leveraging
the ability of the exim user account to specify an alternate configuration
file with a directive that contains arbitrary commands, as demonstrated by
the spool_directory directive.
Heap-based buffer overflow in the string_vformat function in string.c in
Exim before 4.70 allows remote attackers to execute arbitrary code via an
SMTP session that includes two MAIL commands in conjunction with a large
message containing crafted headers, leading to improper rejection logging.
This issue was resolved and addressed in
GLSA 201401-32 at http://security.gentoo.org/glsa/glsa-201401-32.xml
by GLSA coordinator Mikle Kolyada (Zlogene).