The Sendmail buffer overflow exploit announced in March will almost certainly be programmed into an automated worm within the next six months. Such a worm could do for UNIX systems what Code Red did to the Windows world -- simply because there are so many potentially vulnerable UNIX systems on the network today. . . .
The Sendmail buffer overflow exploit announced in March will almost certainly be programmed into an automated worm within the next six months. Such a worm could do for UNIX systems what Code Red did to the Windows world -- simply because there are so many potentially vulnerable UNIX systems on the network today. Shutting off the Sendmail daemon on 99.9% of the systems in your environment would greatly reduce the potential impact of such a worm.

The Role of the Sendmail Daemon

When I discuss security issues with systems administrators, I find that many of them are confused about the need for a running Sendmail daemon on their systems. This confusion is understandable since, for at least the last two decades, the commercial UNIX vendors have been shipping their operating systems with active Sendmail daemons in the default install. Most administrators simply assume that this daemon is necessary for the users and automated processes running on the system to be able to emit email from the machine.

The reality, however, is that the Sendmail daemon on a machine is only responsible for two things:

  1. Listening on port 25/tcp for incoming messages from outside of the machine
  2. Flushing the local queue of unsent messages on a periodic basis
Having a Sendmail daemon listening on 25/tcp opens the system up for remote exploits such as the recently announced buffer overflow issue. Note that the system only needs to be listening on 25/tcp if it is actively expecting to receive email messages from other systems. In fact, the only systems on the network that receive external email are the machines that are acting as mail servers and mail relays. A given site will typically only have a small handful of these machines (many of which are Windows machines running Exchange anyway). The other 99.9% of the systems on the network are email "clients" -- that is they may emit email messages from time to time, but never expect to receive a message from another machine. On these machines, it is probably best to simply disable the Sendmail daemon altogether in order to eliminate the potential for remote exploits.

The link for this article located at SysAdmin is no longer available.