The Sendmail Vulnerability

[This article was contributed by Tom Owen]

Internet Security Systems issued this sendmail vulnerability report by Mark Dowd on March 3rd. In summary, a legal RFC822 email message with excessive comments in address headers can cause any current version of sendmail to overflow a heap memory area. The LWN vulnerability entry has links to patches, and to the 8.12.8 release which contains the fix. SANS has set up a page with a background information. Fixes are necessary for all sendmails which may see mail regardless of whether they are behind the firewall or without a public address. Eric Allman, the author of sendmail has emphasised that "Everyone should patch as soon as possible, regardless of platform."

This overflow has an pair of ugly aggravations:

• Sendmail normally runs full time as root. It needn't, but that's the way most default sendmail.cf files are written and this allows a sucessful exploit to take full control of the machine.
• Direct access to port 25 is not needed to exploit the vulnerability. Even a machine with a private, non-routable IP address can be reached from the Internet provided the crafted -- but legal -- email message can be relayed to the ultimate target by other systems. To be effective, the exploit has to be able to run asynchronously and phone home out through the firewall before the attacker can take direct control, but that should be possible if the target machine is allowed to browse the web, and of course it's easy for an internal attacker.

This is not the time to join the argument about the extent to which sendmail dominates Internet email. A lot of MX and outbound smart hosts are certainly running sendmail, but the scale of the problem really hits with machines that are not intended to be MTAs. When installing most distributions as a workstation or an application server, it takes a bit of thought not to install sendmail. Few admins are certain that there's nothing -- no vital little cron job or script -- that requires a local SMTP server. With the huge majority of machines on a private subnet or shielded by the firewall, it's simpler and it seems safe to install the MTA offered -- usually sendmail -- just on the off chance. Every one of of these machines now needs to be assessed, and its sendmail patched or removed.

For individual machines, the fix isn't hard. Most distributions have patches out, and with few dependencies, it's a rather easy package to compile and install from scratch. If that's necessary, it's probably simplest to move straight to 8.12.8 rather than apply the patches for earlier versions.

Further out, there are deeper questions for users and distributions. Even if sendmail is still the right solution in 2003, is it right to run it as root?

Abandoning sendmail is a well-trodden route. The venerable system is partly a prisoner of the mail nightmare of the early Internet. Life is easier now without bang paths and BITNET, and modern MTAs benefit from simpler or absent rewriting and use of the least-privilege concepts that have been taught by earlier security problems. Qmail and Postfix both make a fetish of security while still being easier than sendmail -- in simple cases vastly easier -- to set up, and there are others. Unfortunately, mail admins who move their mail servers to other MTAs actually got little protection if they continued to accept the default MTA on workstations. Sites in this position need filters now to stop any exploit reaching the internal network, and then they need to fix those machines as well. Example filters for Exim and for Postfix will need to be reviewed when actual exploits appear.

And those exploits will certainly appear. A proof of concept exploit has already been posted, and more unpleasant varieties are certainly under development. This is the kind of problem that large-scale Internet worms are made of. If you have not yet applied your patches, now would be a good time to do it.

---

(Log in to post comments)