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 email@example.com 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.