Threat Level: green Handler on Duty: Brad Duncan

SANS ISC: EXIM MTA vulnerability SANS ISC InfoSec Forums

Participate: Learn more about our honeypot network
https://isc.sans.edu/honeypot.html

Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!
EXIM MTA vulnerability

We have had several reports regarding a potential issue in the EXIM Mail Transfer Agent (MTA). Thanks John, Greg, Brad & Edward. The issue relates to a privilege escalation and through a specially crafted email.  You can read the information here http://www.exim.org/lurker/message/20101207.215955.bb32d4f2.en.html#exim-dev 

Haven't had a chance to install EXIM and test it myself.  If you have let us know.  In the mean time you may wish to consider running it in unprivileged mode (probably good practice under any circumstances anyway).  Instructions on how to do that can be found here http://www.exim.org/exim-html-3.20/doc/html/spec_55.html

Mark H

Mark

391 Posts
ISC Handler
From : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606527

The exim config allows constructs like ${run{...}} that execute shell
commands, then calling "exim -C<myconfig.conf>" executes those commands, if
they are in specific lines they are executed as root.

Please recompile Debians exim with ALT_CONFIG_PREFIX=/etc/exim4/ and
DISABLE_D_OPTION to prevent (even privileged) users from exploiting this to
upgrade to root.
Anonymous
CVE-2010-4344 exim vuln that allows remote code execution as 'exim'
CVE-2010-4345 exim vuln that allows privilege escalation 'exim' to root


http://marc.info/?l=oss-security&m=129197453222580&w=2
Anonymous
Seems to affect Exim before 0.70, so that includes versions in Debian lenny and etch. Exim is Debian's default MTA and is often installed automatically even on desktop machines.

A buffer overflow exploit currently seen in the wild can be avoided with a configuration workaround of "log_selector = -rejected_header". Debian's security update for lenny, or the version already in squeeze, has a more robust fix.

That exploit creates a malicious configuration file in the /var/spool/exim4 folder on Debian, so that's a good place to check for evidence of intrusion. The timestamp on that directory should rarely change, except to create gnutls-params when Exim is restarted. Successful escalation to root privileges could allow the attacker to hide evidence of the intrusion though.

The privilege escalation from 'exim' to 'root' is likely to affect all Debian versions but isn't yet fixed. This should only be an issue when some other vulnerability exists (such as the one Debian has patched today). No doubt that will be fixed out of caution, after more testing is done.

An excellent summary is here:

http://www.exim.org/lurker/message/20101210.164935.385e04d0.en.html
Steven C.

171 Posts
We're seeing a few unmanaged VPS customers that have been compromised. A tell-tale sign is the tiemstamp on /sbin/sysctl reflecting the time of compromise.
Anonymous

Sign Up for Free or Log In to start participating in the conversation!