CERT Advisory CA-2003-07 has disclosed that a serious, remotely exploitable buffer overflow vulnerability has lurked undiscovered for years in the popular Sendmail SMTP server. Sendmail is responsible for handling more than 50 percent of the e-mail on the Internet.

Details
Although there were earlier alerts concerning this vulnerability, it was the group of Polish ethical hackers known as the Last Stage of Delirium that first published a proof of concept for this vulnerability and demonstrated how it could be used for an attack. According to this group, the problem lies in the crackaddr(char* addr) function of the headers.c file, which is a security mechanism.

The original report of this vulnerability came from Internet Security Systems (ISS), which indicated that an attacker could penetrate a Sendmail server simply by sending a specially crafted e-mail message to the server, resulting in remote access to root or superuser control of any vulnerable server, even without the attacker having any specific knowledge of the software running on the server.

The ISS advisory describes the threat as involving the way Sendmail checks the “To”, “From,” and “CC” fields. A static buffer is used to store these fields. The problem occurs in one of the several security-checking features used to ensure that the data in these fields are correctly parsed once the buffer is filled up.

ISS reports having “demonstrated that this vulnerability is exploitable in real-world conditions.” The company specifies testing and finding the vulnerability to be readily exploitable on x86 systems but says that it may be exploitable on other types of systems as well.

In its proof of concept, the Last Stage of Delirium explicitly stated that there may be other, unexplored vulnerabilities it’s not aware of but added that many systems are probably not vulnerable to this exploit.

Risk level–critical
Although there is some debate over just how many systems can actually be exploited by this flaw (see “Mitigating factors” below), the Sendmail vulnerability does exist on a large number of installations, and it is not a good idea to leave the vulnerable version on your servers while the debate rages on. There is no debate about whether the vulnerability can potentially lead to serious damage—only whether it can be easily exploited on all platforms or only on a few.

Applicability
The CERT Advisory specifically lists the following versions as vulnerable:

  • Sendmail Pro (all versions)
  • Sendmail Switch 2.1 prior to 2.1.5
  • Sendmail Switch 2.2 prior to 2.2.5
  • Sendmail Switch 3.0 prior to 3.0.3
  • Sendmail for NT 2.X prior to 2.6.2
  • Sendmail for NT 3.0 prior to 3.0.3
  • Open source Sendmail versions prior to 8.12.8 (including UNIX and Linux versions)

To help identify potentially vulnerable systems, ISS has released these assessment checks:

Mitigating factors
As I mentioned above, there is an ongoing debate about whether this Sendmail vulnerability is a widespread threat or, because of various mitigating factors, it can be exploited on only a few systems. The Last Stage of Delirium says that its preliminary test of this exploit showed it wasn’t as dangerous as first thought:

“Due to the nature of the discussed Sendmail vulnerability it seems that it is unexploitable on most of commercially available UNIX systems. It also doesn’t seem to be exploitable on most of the default SMTP installations of x86 based open source systems. This leads to the conclusion that the overall impact of the vulnerability is rather limited and not so significant as it might be thought.”

However, the group’s analysis covered only one possible exploit mechanism on UNIX and Linux (Slackwave and Red Hat) servers.

In a BugTraq message, Sendmail’s Eric Allman responded to the Last Stage of Delirium’s downplaying of this vulnerability by saying, “Besides direct execution path exploits, there are other variables that are not pointers that have security implications; finding one of them within range will be more difficult, but probably not impossible….Everyone should patch as soon as possible, regardless of platform.”

Fix–patch or update to Sendmail version 8.12.8.
Sendmail.org has produced patches for versions 8.9, 8.10, 8.11, and 8.12, but the vulnerability is also found in earlier versions. For those who are using earlier versions of the software, Sendmail.org recommends open source users of versions prior to 8.9 take the opportunity to update to the latest version. Sendmail Inc. is also making a binary patch available for commercial customers.

ISS has developed a “virtual” patch for the Sendmail vulnerability using the security company’s Dynamic Threat Protection platform. Updates are available from the ISS Download center.

Final word
ISS reports that it notified Sendmail on Jan. 13, 2003, and received confirmation from the vendor on the same day. ISS worked with the vendor and reports good cooperation. It did not make a public announcement of the threat until March 3, 2003.

Still, I have to wonder why the Last Stage of Delirium hackers felt it was necessary to publish a detailed proof of concept for this Sendmail bug, which no one was denying existed. The first group to discover a vulnerability (ISS, in this instance) may have a good reason to publish proof of concept showing how to engineer an attack, especially if vendors are ignoring them. However, what legitimate purpose is served by doing so after everyone admits there is a problem and moves to fix it?

The usefulness of this posting would be more obvious if the Last Stage of Delirium had completely explored the vulnerability and was demonstrating that it really wasn’t very dangerous. But its BugTraq report began, “We did not perform full analysis of this issue,” and ended, “However, we cannot exclude that there does not exist another execution path in the Sendmail code that could lead to the program counter overwrite.” On the other hand, according to the report, the exploit doesn’t really work very well. In that light, I guess there was little harm in publishing the exploit unless someone uses it to explore other ways to take advantage of the flaw.