Remote Exim Exploit In the Wild 90
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.
Re:First comment! (Score:4, Funny)
Re: (Score:2)
More than four people use Debian, where Exim is standard and works out of the box.
Re: (Score:3)
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: (Score:2)
I use Exim. I have great clanking balls.
Re: (Score:1)
Re: (Score:2)
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).
Re: (Score:1)
[0]
1. Try it
2. It works.
3. Profit???
Who knew? (Score:1)
Is exim supposed to be difficult? Damn. Maybe I'm better than I thought (unlikely) or you're lamer than you think (ref. Dunning-Kruger Effect.)
Whichever.
Re: (Score:3)
This isn't FUD. http://www.exim.org/lurker/message/20101209.150448.ee9f5ce6.en.html [exim.org]
News? More like olds. (Score:2)
Welcome to a week ago. Oh, and security guys -are- picking up on it. Stop following companies/press and start following persons.
cPanel (Score:3)
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: (Score:1)
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: (Score:2)
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 [cpanel.net]
Re: (Score:2)
noexec ain't bulletproof:
root@bender:/mnt# mount -o noexec,size=10M,nr_inodes=100 -t tmpfs tmpfs ./tmp/ ./ ../ ./test.sh ./test.sh: Permission denied ./test.s
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#
-su:
root@bender:/mnt/tmp# sh
Re: (Score:3)
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: (Score:2)
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 /var/spool/exim4
in
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: /var/spool/exim4/setuid}}${run{/bin/chmod 4755 /var/spool/exim4/setuid}}
spool_directory = ${run{/bin/chown
root:root
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 r
Re: (Score:2)
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: (Score:2)
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 pri
Re: (Score:2)
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 comma
Re: (Score:2)
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 (no
Re: (Score:2)
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 ha
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
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: (Score:2)
/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: (Score:2)
It might be covert if you support starttls. I agree, best to apply the patches...
Re: (Score:2)
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: (Score:2)
Does any IDS or IPS actually do that?
Re: (Score:2)
Sourcefire makes a box that does it, as do some other companies.
Re: (Score:2)
Sounds like some pretty neat duct tape.
Was fixed in 4.70 according to Mailing List (Score:5, Informative)
http://www.exim.org/lurker/message/20101210.071922.233697ac.en.html [exim.org]
"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 [exim.org]
It was fixed in 4.70, but not in the version currently in debian
stable.
James E. Blair
UC Berkeley"
Re: (Score:2)
Re: (Score:3, Informative)
Re:Was fixed in 4.70 according to Mailing List (Score:5, Informative)
Boring target.
Re: (Score:3)
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: (Score:2)
Foiled again by documenting bugs in bug reports. When will they ever learn? Security by obscurity is the _only_ way.</troll>
Re:Was fixed in 4.70 according to Mailing List (Score:5, Informative)
Debian has released a DSA and a fixed version for Stable. See Debian Security Advisory DSA-2131-1 and Debian Security [debian.org].
Re: (Score:3)
Link for the above DSA: http://lists.debian.org/debian-security-announce/2010/msg00181.html [debian.org]
Wow ... "Electric Fence spotted this problem" (Score:3)
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: (Score:2)
... 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
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.
Thank God I use sendmail! (Score:1)
Because sendmail has such a long record of resistance to security bugs :)
it's an MTA not a client (Score:2)
fourth post: "Exim is the MTA..."
if you don't know what an MTA is, sendmail, qmail and postfix are other examples.
Re: (Score:1)
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: (Score:2)
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: (Score:2)
I'd ask you to hand in your geek card, but it appears that you were never issued one to begin with.
Re: (Score:2)
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” [google.com] before I gave up and just asked.
Debian patched it today (Score:5, Informative)
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 (Score:1)
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: (Score:2)
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.
There IS some idiocy in FOSS at times ... (Score:1)
[... and there goes my karma :( ] .( ], hate blobs. I can do with less functionality if only the software is free.
Actually, exim was never the thing to do, and yet Debian had it in default.
Just read the archives, and this has been under discussion ever since. OpenBSD has sendmail, likewise, and this has been under discussion ever since.
I am totally a FOSS person [and there goes even more karma
And some perceive postfix as 'not free enough' and so forth. Whatever, relevant is, that exim has always been a do
Re: (Score:3)
Stop whining about your karma, and learn to format paragraphs.
Re: (Score:2)
Impossible to configure? No, not really, even in v3. It is actually pretty nice to use if you have a complicated configuration.
Re: (Score:2)
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: (Score:2)
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.
Re: (Score:2)
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: (Score:2)
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 scare
Re: (Score:2)
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.
Exim hate (Score:4)
Re: (Score:2)
Re: (Score:2)
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: (Score:2)
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: (Score:3)
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.
Milters? (Score:2)
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: (Score:2)
Re: (Score:1)
Sendmail has one redeeming feature: milters.
Another very cool feature is throttling by cpu load (envious postfix user here).
"Exim haters" is pure fiction (Score:2)
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
Re: (Score:2)
I've been running Exim on two servers for the past 5 years now. Never had a problem either.
Sure glad all my servers run Sendmail (Score:5, Funny)
Bet you never thought you'd read that in response to a security announcement. :)