Internet Holes - The Sendmail Maelstrom

Copyright(c), 1996, Dr. Frederick B. Cohen

Series Introduction

The Internet is now the world's most popular network and it is
full of potential vulnerabilities. In this series of articles, we
explore the vulnerabilities of the Internet and what you can do to
mitigate them.

An Introduction to Sendmail

Sendmail is the program that handles electronic mail for the
operating system in most Unix-based systems. Sendmail is an enormously
complex program that provides services ranging from forwarding mail
between computers to compressing and decompressing files for more
efficient transmission.

In its complexity lies sendmail's downfall. As a point of
reference, three major sendmail attacks were detected in the first 6
months of 1995, each of which allows an external attacker to take over
the host using sendmail for processing its mail. Considering that
sendmail holes have been detected on a regular basis for a period of
several years, it is very likely that more holes will be found for a
long time to come.

As the result of a user mail request, the sender establishes a
two-way communications channel to a receiver. The receiver may be
either the ultimate destination or an intermediate. SMTP commands are
generated by the sender and sent to the receiver. SMTP replies are sent
from the receiver to the sender in response to the commands.

Once communication is established, the sender sends a MAIL
command indicating the sender of the mail. If the receiver can accept
mail it responds with an OK reply. The sender then sends a RCPT command
identifying a recipient of the mail. If the receiver can accept mail
for that recipient it responds with an OK reply; if not, it responds
with a reply rejecting that recipient (but not the whole mail
transaction). The sender and receiver may negotiate several recipients.
When the recipients have been negotiated the sender sends the mail data,
terminating with a line containing only a '.'. If the receiver
successfully processes the mail data it responds with an OK reply. The
dialog is purposely lock-step, one-at-a-time.

On its face, this seems like a very simple process, and it
should be, but it's not.

A Sampling of Sendmail Attacks

Here is an example of the notifications about sendmail attacks from the
Computer Emergency Response Team (CERT) at Carnegie-Mellon University:

On Jan 29, 1990, they learned of and verified break-ins on several
Internet systems in which the intruders exploited a vulnerability in the
Sun sendmail program. CERT provided no details, however attack scripts
indicated that Sendmail allowed recipients with names like '|' which
resulted in running programs with the inbound mail as the input.

February 22, 1991, in making the repair suggested by CERT to the
previous attack, another hole was created. They forgot to remove the
Setuid file protection setting that allowed the mail system to be
used to become the superuser.

November 4, 1993, a vulnerability was found in most versions of
sendmail that allows unauthorized remote or local users to execute
programs as any system user other than root. Again, but use of a shell
command hidden in a mail message header.

July 14, 1994, two vulnerabilities in some vendors' versions of
sendmail were found. One, in the debug option, enabled local users to
gain root access. The other, in the error message header option,
enabled local users to read any file on the system.

January 26, 1995, local users (users that have an account on the
system) can create or modify root-owned files on the system and can
thereby gain unauthorized root access. But the hole was bigger than
they thought...

February 22, 1995, This problem could allow an intruder to gain
unauthorized access to your system remotely (that is, without having
access to an account on the system). This was caused by forged
identification daemons on a remote host whose information was trusted by
sendmail and passed as a command line to a command interpreter.

In addition to these attacks, sendmail can easily be used to
forge electronic mail. All you have to do in many systems is to claim
you are from a different site (make up a site name), and your mail will
be forwarded as if it were legitimate. This is the sendmail correlary
to:

Fred's First Law of Attacking Computers:
Lie - chances are they'll believe you.

Computers can't tell the difference between the truth and a lie,
and neither can many humans. But unlike most humans, in the case of
most modern computers, even the simplest of lies work, and the same lie
works again and again until the computer is fixed. Then another lie will
probably work.

In the case of sendmail, forged email has been actively used for
more than five years and continues to thrive as a means for an
attacker's ends.

It is almost certain that we will see more such sendmail
vulnerabilities for a long time to come. The reason is simple. The
people who write these programs do things the easiest way they can
instead of considering all of the possible ways an attacker could
exploit their work.

What Can We Do About It?

Not a lot, I'm sorry to say. Unfortunately, electronic mail is
a critical function in current networks, and it has become so complex
and has had so many features added, that it's almost impossible to even
tell what the programs that handle it really do anymore. But there are
alternatives:

Firewalls can be useful tools in protecting agsinst sendmail
attacks, and sendmail is very easy to configure for a firewall
application. One way to configure sendmail in a firewall is by
providing a bastion host that only performs sendmail forwarding
functions. By configuring this host with a read-only disk, no user
accounts, and no services other than sendmail, an attacker is severely
limited in their ability to corrupt the system itself or use it as a
platform for launching attacks against other sites. This can be done for
only a few thousand dollars.

Secure versions of sendmail-like programs are available, however,
none of them have been shown to completely solve the sendmail problems.
They are more secure than sendmail per-se, but they are not absolutely
secure.

One way to limit sendmail's effect is by using a multi-level
secure operating system which enforces compartments. In such a system,
no information can flow between compartments except through
specially-written operating system programs. Sendmail can be configured
to operate in one compartment, while other services are in other
compartments. This separation limits the impact od sendmail attacks.

Someday soon, sombody will come up with a small, minimal, secure
sendmail forwarding program that can be used to secure normal sendmail
functions on any host. Once this happens, it will be another solution
to the sendmail problem.

As we go to press

Within the last two weeks, a new hole that exploits sendmail to
cause the system logging daemon to execute commands for the attacker as
the superuser on a Unix machine has been discovered.

Summary

Sendmail - you can't live with it, you can't live without it -
or can you?