Sendmail.com - Product Security — Product Security Advisory SA-200605-01

Sendmail was recently notified by an open source sendmail user about a problem message that was stuck in a queue. To the best of our knowledge, this type of attack is not currently in use and the problem was found through a report of an isolated and unintentional incident.

How difficult would it be for someone to exploit this vulnerability?

The vulnerability is easy to exploit. Constructing a message with the malformed MIME necessary to exploit the vulnerability is easy.

Has anyone been impacted by this?

Other than the initial reporter, Sendmail is not currently aware of any other attacks against this exploit. However, this information is now public and an attack against the exploit is more likely.

What should a user look for to know if they have been impacted?

The things to look for are:

Core dumps of the sendmail MTA process attempting to process the mail queue which contains an offending message or system log messages showing sendmail crashing;
Messages in queues which do not get processed, because the queue runner has terminated abnormally before processing the messages after the offending message containing the exploit.

What would happen if someone does exploit this?

Because the queue runner abnormally terminates, the malformed MIME message will cause messages in the queue that would normally be processed after the malformed MIME message to remain in the queue unprocessed.

If the system is configured to save uniquely named core files when processes abnormally terminate, there is the potential for the file system to fill up with core files as the queue runner terminates on every queue run.

Are sendmail MTAs behind my firewall vulnerable?

Yes, sendmail MTAs behind a firewall are vulnerable because this exploit is driven by message content.

Is this a recently introduced problem, or has it been present for some time?

The problem has been in existence since at least version 8.6.6 of the sendmail MTA.

Has Sendmail had similar security issues in the past?

Previous to this issue Sendmail had a vulnerability in certain versions of the Sendmail MTA in March of 2006 and then a few issues were raised in 2003. These vulnerabilities were quickly addressed and resolved by Sendmail. Although this type of occurrence is not uncommon in the industry, Sendmail has established procedures to quickly and proactively respond to security issues. ISS has in the past complimented Sendmail for our quick and comprehensive response, welcoming our efforts to not only resolve the reported issue, but to deploy additional resources to review and update any related code.

What are you doing to notify affected users?

Sendmail has worked with CERT/CC to manage the communications process for affected vendors, whose products may be based on the sendmail MTA software. We are also notifying the open source community and our commercial customers about this issue. Sendmail is committed to providing to our customers immediate availability of patches and upgrades to correct it.

What should users do until they can install the patches?

If you are unable to immediately install the patch described in the Solution section below or if there is not a patch available for your version, you can protect your system by using one of these workarounds:

The Sendmail Consortium is releasing an open source mail filter for UNIX(tm) systems which blocks messages that may trigger this problem. For more information on this filter, please see the Sendmail-SA-200605-01 Security Advisory: http://www.sendmail.com/security/
If your operating system limits stack size, remove that limit for sendmail's startup. This will make the attack more difficult to accomplish, as it will require a very large message. Also, by limiting the maximum message size accepted by your server (via the sendmail MaxMessageSize option), you can eliminate the attack completely.

To remove the stack size limit, use one of the following commands in your sendmail startup script (by placing the command in the startup script, only sendmail should be affected):

ulimit -s unlimited (sh, bash, ksh) limit stacksize unlimited (csh, tcsh, zsh)

For more information on adjusting stack size limits, please see the Sendmail-SA-200605-01 Security Advisory.

Configure your MTA to avoid the negative impacts listed above:

Turn off core dumps for sendmail using one of the following commands in your sendmail startup script (by placing the command in the startup script, only sendmail should be affected):
ulimit -c 0 (sh, bash, ksh) limit coredumpsize 0 (csh, tcsh, zsh)
For more information on turning off core dumps, please see the Sendmail Knowledge Base article referenced below.
To prevent queued jobs from being ignored, you can either:
Enable the ForkEachJob option at the cost of lower queue run performance and potentially a high number of processes (one per queued item), or
Set QueueSortOrder to random, which will randomize the order jobs are processed. Note that with random queue sorting, the bad message will still be processed and the queue run aborted every time, but at a different, random spot.
For more information on changing queue run behavior, please see the Sendmail-SA-200605-01 Security Advisory: http://www.sendmail.com/security/

What should the users do to request the patches?

Sendmail is notifying our commercial customers about the patches for specific product releases and platforms and providing the information on how to download and obtain these patches or upgrades.

Open source users can get sendmail 8.13.7 from ftp://ftp.sendmail.org/pub/sendmail/ and should also subscribe to sendmail-announce mailing list for any other updates by sending mail to sendmail-announce-request@lists.sendmail.org.

What about 3rd party vendors using the sendmail MTA?

Check with your vendor. Sendmail has worked with CERT/CC to notify the vendors and provide source code patches. Please monitor CERT/CC vulnerabilities page at http://www.kb.cert.org/vuls/id/146718 for updates on patch availability from other vendors.

What versions of the Open Source sendmail MTA are affected?

Versions of the MTA prior to 8.13.7 are affected by this issue. Open source patches are available for 8.12 and 8.13 versions. Visit http://www.sendmail.org/ for the latest information and links to the 8.12 and 8.13 patches. The Sendmail Consortium strongly suggests that users upgrade to 8.13.7. Please refer to http://www.sendmail.org/releases/8.13.7.html for more details.

How important is this issue, how quickly should I plan to upgrade?

Sendmail's threat assessment of this issue is low. This vulnerability does not have serious impacts on end users, and can be easily worked around. A workaround or upgrade should be deployed as soon as possible.

What are my options?

Patch your system;
Deploy the open source milter made available by the open source consortium;
Remove the stack size limit for the sendmail process; or
Configure your MTA to avoid the impacts.

See "What should users do until they can install the patches?" above for more information.

Will this issue shut down my server?

No, this vulnerability will not shut down your server, but it may interfere with the delivery of queued mail or potentially fill your disk and prevent acceptance of new mail.

Will this issue cause me to lose mail?

No, this vulnerability will not cause you to lose mail, but if your disk becomes full and can no longer accept or deliver mail, some mail may be bounced.

Is this issue related to the recent security vulnerability in certain versions of sendmail Mail Transfer Agent?

No, this vulnerability is not related to the recent Sendmail MTA security vulnerability. However, the Switch 3.1.8 and 3.2.0. release also provides an upgrade to that addresses the issue documented in that advisory.

What are all the new changes included in the Switch 3.1.9, Switch 3.2.1, and Sentrion 1.5.2 patch?

Changes to the sendmail MTA binary to resolve this vulnerability
In the Sentrion 1.5.2 patch, support for Anti-spam Cloudmark Cartridge 3044.1.0.12 has been integrated

How can I verify this is a legitimate security advisory?

Customers can contact Sendmail Technical Support as listed on http://www.sendmail.com/support/contact/ to verify the authenticity of this advisory. The email notification sent to Sendmail customers is signed with PGP, using the Sendmail, Inc. Security Officer PGP key, available at: http://www.sendmail.com/security/security-officer.asc. In addition, a PGP signed copy is available for download at: http://www.sendmail.com/security/, signed with the same key.

How was this issue discovered?