In-Depth

Sendmail Vulnerability Exposed

Flaws found in Web’s most widely used E-mail transport

• By Mathew Schwartz
• 03/12/2003

Sendmail is a mail transport agent used on many Unix-based operating systems; a majority of today’s e-mail flows through Sendmail of one type or another. In particular, in Sendmail versions 5.79 through 8.12.7, an attacker can use an e-mail header field to cause a buffer overflow in the receiving Sendmail program and gain root or superuser access to the server. If attacked, unpatched servers would not record the attack.

Sendmail urged all companies to upgrade to Sendmail 8.12.8 or apply a patch. For updates, see http://www.sendmail.org.

The vulnerability is particularly notable in that no companies seem to have been hurt. How did that happen? After Internet Security Systems Inc. (ISS) found the vulnerability in January and alerted the Department of Homeland Security (DHS), DHS coordinated a response. After DHS communicated it to some—but not all—software vendors, it decided to sit on the information for a week to let everyone build patches. It was a calculated risk—experts kept their ears to the ground and didn’t hear about anyone crafting an attack to exploit the vulnerability. Of course, they’d have to boast.

Back when SQL Slammer appeared, Marcus Sachs, the director for communication infrastructure protection at the White House Office of Cyberspace Security, noted that, “Right now while we're in a time of transition, it is a little tough to do the coordination.” He expected coordination to be smoothed out by the summer. At the time of the attacks, three different agencies—the Federal Computer Incident Response Center (FedCIRC), the National Infrastructure Protection Center (NIPC), and the National Communication System (NCS)—have been at least partly absorbed into the DHS’s Directorate of Information Analysis and Infrastructure Protection. (Hopefully that will lead to acronym reduction.)

The Sendmail attack was an early test of a not-yet-finalized DHS. Both DHS and the overall information-release gamble seem to have paid off. Many vendors were able to issue patches when DHS made the vulnerability public.

On the other hand, the Sendmail vulnerability, which has existed unknown for years, might not be so bad.

Writing to the Bugtraq mailing list, a group of Polish researchers known as the Last Stage of Delirium reported that “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.”

By the group’s own admission, however, testing was limited. “We cannot exclude that there does not exist another execution path in the [S]endmail code,” that could lead to a successful attack. So patch those systems.

Managing The Endless Patch Cycle

This vulnerability, like so many others, played out like this: An attack, or a software company alert, lets administrators know that a product in their environment might be vulnerable to a security exploit. The vendor rushes out a patch, and users test and deploy that patch, though not always very quickly.

Many believe that process needs to change.

“The thing with security patches is that they're kind of a tricky thing, because once a vulnerability is known and a patch is made available, you want to be able to get that patch out as quickly as possible. But it is what it is—a patch. Typically people feel really comfortable with service releases, because those have been rigorously regression tested, whereas a patch is fixing a specific vulnerability, in a specific configuration, that might not have gone through such a rigorous testing process,” says Joe Sturonas, chief technology officer (CTO) at Spirian Technologies Inc in Chicago.

At a higher level, of course, it might help if vendors had a better idea of how their customers deploy software, and companies had better idea of what software actually runs on their computers. For vendors, the challenge is knowing which customers use which products, then targeting them with vulnerability and update information.

“With an IT organization inside a company, it's the same way,” says Kim Woodward, vice president of marketing for Spirian. “One of our customers is a large bank that has [about] 30,000 users, and if you have to release a patch, you don't want to have to release to people unless they need it.”

That’s where Spirian says its products can help. The company, which began in 1996, sells its Spirian Serviceability to software and hardware companies to help them deliver updates to customers. Its Spirian Manageability product helps simplify day-to-day management of software operations for IT administrators, including updating, patching, virus fixes, and appropriate software license use. Administrators can install a small asset-tracking software agent on all of a company’s computers to keep track of what’s running, and where, via HTTP, so patches are sent only to the desktops that need them. Beyond trying to prevent so many vulnerabilities, once it comes to patch time, software vendors can only do so much. “Software companies know what customers purchased, but not necessarily what they've deployed for end use,” notes Woodward. For example, though a company bought a product upgrade, the vendor has no way of knowing if it’s even been installed yet.

Don’t expect perfect code from vendors anytime soon, of course. Yet as the recent Sendmail vulnerability demonstrates, even if new code were perfect, there will always be plenty of exploitable code still in use. “I think that because of the attention that these vulnerabilities have produced, and the vulnerabilities that existed in Sendmail—Sendmail has been around for such a long time—that shows us that there are buffer overflow opportunities in virtually any product that exists out there,” says Sturonas. Expect more attacks that take advantage of those vulnerabilities.

As a result, “software companies and IT organizations alike really need to be able to assess what the vulnerabilities that already exist are out there, and how can they better prepare for the next vulnerability or virus that occurs,” he says.

In fact the government is already attempting something similar—a single, consolidated source for all patch upgrades called Patch Authentication and Dissemination Capability (https://padc.fedcirc.gov/). Authorized government users can download patches and notifications. FedCIRC validates that the patch came from a reliable source.