[cobalt-users] Sendmail vulnerabilities and versions

[David Shugarts <Azimuth@xxxxxxxxxxxxxx>]

This will reveal that I don't know much about Sendmail, but that's merely
the truth.

About six weeks ago I upgraded my Qube 3 by a clean install of OS 6.4 and
then all the patches. I have kept up through BlueLinq and there is nothing
left to update. The latest Sendmail update was
Qube3-All-Security-4.0.1-16620.

I just recently began to get spammed by a machine that is on my local block
of addresses--e.g., if I am on 150.100.123.61 then this machine is on
150.100.123.63.

I began to investigate and found nothing in the Cobalt GUI pages that would
explain it. But by chance and reading various help pages from other people,
through Telnet I found a file at etc/mail/access which had three entries:

# Cobalt Access Section Begin
10.6.18 RELAY
150.100  RELAY
mydomain.com  RELAY

So it appears that I have been set up as a relay server, without my
knowledge. As I construe the second entry, the Qube is willing to act as a
relay server for the entire block of addresses from 150.100.0.0 through
150.100.255.255. The thing is, I don't know how this got set--by some
default of the Qube 3 installation under OS 6.4, by an upgrade to Sendmail
through Cobalt, or by a vulnerability accessed and now being exploited.

I turned to the Cobalt GUI and specifically blocked the offending machine.
The entires in etc/mail/access changed--"badmachine.com" was added as:

badmachine.com    550 Mail rejected due to possible SPAM

It appears that the spam relaying has stopped, but it will be a while before
I can be sure, as some rejected messages are still coming in from five days
ago.

I wondered about relay server issues, so I now checked the machine through
http://email-test.com. I passed the relay server test, but they also
informed me that I appear to be running Sendmail 8.10.2. Quoted at the
bottom of this message is their report. (I note that they have a vested
interest in selling me a replacement for Sendmail.)

Sendmail.org says the current version is 8.12.10. So if the statement above
is true, Cobalt is nowhere near up to speed with Sendmail, and even the
latest Sendmail has vulnerabilities.

Advice at any and all levels would be appreciated.

--Dave Shugarts


=============

Report from email-test.com:

[mydomain.com]:25 appears to be running Sendmail version 8.10.2/8.10.2 Below
is a list of bug fixes in this and subsequent versions of Sendmail.

NOTE: Only security bugs are included in the bug list for Sendmail - please
refer to the release notes for a complete list of bug fixes.
Version Bug
8.12.7/8.12.7 SECURITY: Fix a buffer overflow in address parsing due to a
char to int conversion problem which is potentially remotely exploitable.
Note: an MTA that is not patched might be vulnerable to data that it
receives from untrusted sources, which includes DNS.
8.12.7/8.12.7 8.12.9/8.12.9
8.12.7/8.12.7 Fix a potential non-exploitable buffer overflow in parsing the
.cf queue settings and potential buffer underflow in parsing ident
responses.
8.12.7/8.12.7 SECURITY: Fix a remote buffer overflow in header parsing by
dropping sender and recipient header comments if the comments are too long.
8.12.7/8.12.7 8.12.8/8.12.8
8.12.7/8.12.7 SMRSH: SECURITY: Only allow regular files or symbolic links to
be used for a command.
8.12.5/8.12.5 SECURITY: The DNS map can cause a buffer overflow if the user
specifies a dns map using TXT records in the configuration file and a rogue
DNS server is queried. None of the sendmail supplied configuration files use
this option hence they are not vulnerable. Problem noted independently by
Joost Pol of PINE Internet and Anton Rang of Sun Microsystems.
8.12.4/8.12.4 Use TempFileMode (defaults to 0600) for the permissions of
PidFile instead of 0644.
8.12.4/8.12.4 SECURITY: Inherent limitations in the UNIX file locking model
can leave systems open to a local denial of service attack. Be sure to read
the "FILE AND MAP PERMISSIONS" section of the top level README for more
information. Problem noted by lumpy.
8.12.1/8.12.1 SECURITY: Check whether dropping group privileges actually
succeeded to avoid possible compromises of the mail system by supplying
bogus data. Add configuration options for different set*gid() calls to reset
saved gid. Problem found by Michal Zalewski.
8.12.0/8.12.0 SECURITY: Drop privileges when using address test mode.
Suggested by Michal Zalewski of the "Internet for Schools" project (IdS).
8.12.0/8.12.0 SECURITY: Check for group and world writable forward and
:include: files. These checks can be turned off if absolutely necessary
using the DontBlameSendmail option and the new flags:
8.11.0/8.11.0 SECURITY: sendmail depends on snprintf() NUL terminating the
string it populates. It is possible that some broken implementations of
snprintf() exist that do not do this. Systems in this category should
compile with -DSNPRINTF_IS_BROKEN=1. Use test/t_snprintf.c to test your
system and report broken implementations to sendmail-bugs@xxxxxxxxxxxx and
your OS vendor. Problem noted by Slawomir Piotrowski of TELSAT GP.
8.11.0/8.11.0 SECURITY: If sendmail is installed as a non-root set-user-ID
binary (not the normal case), some operating systems will still keep a
saved-uid of the effective-uid when sendmail tries to drop all of its
privileges. If sendmail needs to drop these privileges and the operating
system doesn't set the saved-uid as well, exit with an error. Problem noted
by Kari Hurtta of the Finnish Meteorological Institute.