EXIM MTA vulnerability

Published: 2010-12-10. Last Updated: 2010-12-10 01:04:30 UTC
by Mark Hofman (Version: 1)
4 comment(s)

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

Keywords: exim MTA vulnerability
4 comment(s)

Comments

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.

ebf0

Dec 10th 2010
1 decade ago

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

Mark Cox

Dec 10th 2010
1 decade ago

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 Chamberlain

Dec 10th 2010
1 decade ago

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.

TOCICI

Dec 16th 2010
1 decade ago

Login here to join the discussion.


Top of page
Diary Archives