#1 By: Steve Kemp, December 12th, 2010 03:30
The exim4 mail program has a security vulnerability which allows a remote attacker root access to your system. This is a really serious problem, and you should check immediately if any of your servers are vulnerable. If your server does use exim, and anything but the very latest version, it is very likely to be vulnerable.
On the whole, it is only Debian servers that will be vulnerable. Newer versions of CentOS and Ubuntu did not use exim, and Windows systems won't either. BUT if you're not sure, you should check, as a compromised server will need reinstalling from scratch.
In order to check and fix a vulnerable server, you will need root shell access and about 10 minutes.
To check what version your server is running, run:
You're safe if any of the following is true:
[*] The version is 4.70 or later;
 The build date is Friday 10th December 2010 or later;
 It says "No such file or directory" (i.e. you don't run exim).
All other versions are vulnerable, and you must take action. Repeat the above check after you've taken action to ensure that the build has changed. Note that the version number won't change after a successful upgrade, but the build date should.
The action you take depends on what Operating System you are running.
If you are running Bytemark vhost or Symbiosis, newer systems may upgrade themselves on early Monday morning, but older ones (running etch) cannot. Type
to find out which version of Debian your system is running, and follow the instructions for Debian.
If you're running Debian/lenny or recent versions of Ubuntu, run:
If you're running Debian/etch, you will need to download packages separately. We've built them for you, but you need to change your package sources. This should be all you need to do:
echo 'deb http://repo.bytemark.co.uk/exim4/etch ./' >>/etc/apt/sources.list
If you're running CentOS, type:
As a last resort, if you want to temporarily suspend mail deliveries rather than risk a compromised server (we would strongly recommend this if you can't deal with this immediately), you should run:
iptables -I INPUT -p tcp --destination-port 25 -j REJECT
And to lift the block after you have addressed the problem, run:
iptables -D INPUT -p tcp --destination-port 25 -j REJECT
We don't have instructions for other Operating Systems - if you are worried please contact firstname.lastname@example.org and we will do our best to help. However we can't make any guarantees that your server hasn't already been compromised - the problem was revealed on Friday and it has been a race to prepare ourselves and get the word out.
#2 By: Mike Rogers, December 12th, 2010 06:46
I got stung by this vunerability literally a couple of hours after it had been publicised on the web. I'd check you machine for root kits (use rkhunter) even if it looks like your version of exim is OK, as my attack happened before the security patch got installed by my daily cron job. You may have got a rootkit infection and then had your server upgraded.
#3 By: Neil Turner, December 12th, 2010 07:13
Just to clarify, if the version number is 4.69 but the build date is 10th December 2010, that means it's patched?
#4 By: Joe Freeman, December 12th, 2010 07:20
This is probably really obvious, but just thought I'd mention that on my machine the exim binary is at '/usr/sbin/exim' not '/usr/sbin/exim4' as mentioned above. Thanks for making me aware of this vulnerability.
#5 By: Steve Kemp, December 12th, 2010 07:21
Neil - Yes, if it was built "recently" that means it was updated.
#6 By: Patrick Heath, December 12th, 2010 07:24
also to clarify......
running '/usr/sbin/exim4 -bV' gives 'No such file or directory'
but '/usr/sbin/exim -bV' gives 'Exim version 4.63'
will this still be vunerable? i'll be upgrading anyway and have applied the block. How do i know if i have been hit, can't see anything unusual in the logs
#7 By: Steve Kemp, December 12th, 2010 07:42
NOTE - If you've updated your exim then the version number will not change.
Instead you'll change from running a vulnerable 4.69 to a fixed 4.69.
#8 By: Paul Waring, December 12th, 2010 07:45
How can I tell if either of my Symbiosis VMs have been compromised? I've run rkhunter on both and the only non-OK messages I get are:
Performing malware checks
Checking running processes for suspicious files [ Skipped ]
Performing trojan specific checks
Checking for enabled inetd services [ Warning ]
#9 By: Paul Waring, December 12th, 2010 07:47
Also, if you're running Symbiosis you will NOT have been upgraded on Saturday morning, as the cron job for updates only runs Monday to Friday.
#10 By: Steve Kemp, December 12th, 2010 07:48
If you get no obvious alerts from rkhunter then you're probably OK.
But there is no 100% reliable way of telling if you've been compromised - the best you can do is be alert for unexpected changes, processes, or logins.
#11 By: Sergei Lewis, December 12th, 2010 08:07
Does anybody know if Exim 3 is affected by this? The implication from the developer lists is that the bug was introduced in string_format in exim 4, but I've not found any definite confirmation one way or the other...
#12 By: Matthew Bloch, December 12th, 2010 08:36
Thanks for the corrections on the binary name & Symbiosis upgrade schedule - have updated the instructions accordingly.
A few people have asked "how do I know whether I've been compromised"? Unfortunately if an attacker has done a good job of it, you won't know until we get complaints about your machine spewing spam or DoS attacks. Since I'm expecting some new exploit code to be rampant over the next few days, it seems likely that any rootkit detector is going to miss newer attacks, and give you a false sense of security. So that's no comfort at all, sorry. I suspect we can answer that question a bit more authoritatively in the new year when the attackers have honed their tools a bit more, and the rootkit detectors have caught up.
#13 By: Neill Jones, December 12th, 2010 08:46
Although from Matthew's comments, this won't give you peace-of-mind at least not quite yet, here is the instructions for rkhunter for newbies to this (like me :nerd: )
apt-get install rkhunter
and the logs are stored (at least on Debian/Lenny) in
which will explain any warnings that it produced.
#14 By: Marianne Promberger, December 12th, 2010 08:46
system admin newbie here. Thanks for the heads up!
I've checked and had been updated with the 10/12 version (presumably with cron update/upgrade), and rkhunter only returns info about running FTP. (gave warnings first that went away after "sudo rkhunter --propupd"
Regarding Matthew's latest post, I assume this means the best course of action is to keep periodically running rkhunter (and upgrading rkhunter through aptitude)?
Do you have pointers of other steps I could take? Eg, I wouldn't mind putting a strong delay on outgoing mail? Or, could I set up getting an email sent (to my private address) if (lots of) mails are sent out from my server? (this would work for me as the server is generally v low traffic). I assume a rootkit could get around all that, but someone would have to manually detect this, so an automated script might not?
#15 By: Charles Holdsworth, December 12th, 2010 10:50
FWIW we were compromised at 4pm yesterday (on an old server we were going to rotate out shortly, typically). Looks like this could be a long day...
#16 By: Clarke Brunt, December 12th, 2010 10:51
Thanks Steve, Matthew, anyone else at Bytemark, for the email notification. Duly updated my exim and run rkhunter - seems OK so far.
Regards Marianne's comment above "keep periodically running rkhunter (and upgrading rkhunter through aptitude)?": I wonder what chance of Debian rkhunter being sufficiently up to date. 'Stable' currently has 1.3.2, while latest is 1.3.8. I downloaded latest rkhunter without using apt etc., and just followed the instructions for a 'freestanding' install.
#17 By: Rick Crust, December 12th, 2010 11:43
I have three domains on Bytemark, all of them using Google Apps to handle email.
I have no incoming email at all. The only outgoing email is directly from my Wordpress installations.
Is there any reason why I cannot remove exim completely?
What is the best way to do that?
#18 By: Steve Kemp, December 12th, 2010 12:25
You'll need some MTA (mail transport agent) to satisfy dependencies - e.g. The cron package will insist you have something installed such that messages your various system cronjobs will send can be seen.
So, yes you can remove exim. But chances are you'll need to install postfix/sendmail/something else otherwise your system will be incomplete.
If you're not accepting incoming mail, and you have no local users though, you could just keep exim present and cause it to not listen externally.
#19 By: Phill Luckhurst, December 12th, 2010 15:54
A big thanks to Bytemark for notifying us all. Great support as usual.
#20 By: Malcolm Kendall, December 13th, 2010 04:24
On etch - the exim4 update required libdb4.6 which is lenny/unstable.
next page →