ISS Discovers A Remote Hole In Sendmail 481
randal writes "A security vulnerability in the Sendmail Mail Transfer Agent (MTA) has
been identified by ISS. This bug can
give an attacker the ability to gain remote root access to the
targeted system. There is no known exploit code of this vulnerability in
the wild at this time, but everyone should upgrade immediately. This
issue affects all versions since 5.79. Open Source sendmail users can
get source for the newest version (8.12.8) as well as patches for 8.9,
8.11, and 8.12 from
sendmail.org.
Commercial Sendmail customers can find patches at
sendmail.com/security.
Most major OS vendors will be releasing patches immediately." Update: 03/03 19:23 GMT by T : Reader Patchlevel points out that RedHat and OpenBSD have already issued patches.Update: 03/03 20:45 GMT by T : Reader Claude Meyer links to an update from SuSE, too. Update: 03/03 22:52 GMT by T : djcatnip points out that Apple has released a software update to patch OpenSSL and Sendmail for Mac OS X 10.2.4, and the Slackware site says they have updated to 8.12.8 as well.
Cross Upgrade to QMail (Score:4, Informative)
Recompiling now....while you're at it... (Score:5, Informative)
APPENDDEF(`conf_sendmail_ENVDEF', `-DMILTER')
Use CPAN to install SpamAssassin:
perl -MCPAN -e shell;
install Mail::SpamAssassin
quit
Then compile spamass-milter. Add this to your sendmail.mc file:
INPUT_MAIL_FILTER(`spamass-milter', `S=local:/var/run/spamass-milter.sock,F=')
Make sure that spamd, spamc, and spamass are all running as daemon processes, and if spamd fails add this to the beginning of the script:
$Sys::Hostname::host = 'my.hostname.com';
Ah...auto spam filtering. Tweak the files in
Re:Cross Upgrade to QMail (Score:2, Informative)
Re:why do people still use sendmail? (Score:3, Informative)
Have you ever try to run 2 instances of qmail on
one machine for exampe?
qmail is very rigid and unfriendly to make configuration tricks and connections to anything
not usual.
Re:Cross Upgrade to QMail (Score:5, Informative)
Slackware (Score:4, Informative)
FreeBSD also patched. (Score:3, Informative)
-- Brooks
Bypasses _some_ SMTP proxies (Score:5, Informative)
However, there are a number of SMTP proxy applications which do "deeper" checking of the message, and which would serve to protect vulnerable servers. Most of these are expensive, and slow.
Realistically, my solution for my servers is as follows:
My problem right now is that the company-accepted standard for spam filtering is milter based, and can only run under Sendmail. If I "hide" the sendmail listener behind another MTA that directly faces the Internet, then my spam filter is ineffective, as I would lose all of the benefit of being able to reject senders and messages based on the remote IP (RBL) and other checks.
The worst drawback of putting the anti-spam Sendmail filter "inside" is that since the message has already been accepted by one of our mail servers, if the spam filter chooses to reject the message, it needs to generate and deliver a "bounce" message, just in case the reject was a "false-positive", to notify the sender.
If the spam filter is on the outermost edge and can talk directly to the sending host, it can return a 5xx "reject" SMTP result code, and it's up to the sending host to generate and deliver the bounce.
Actually no... (Score:5, Informative)
Re:Wouldnt this... (Score:2, Informative)
Most recent large/popular distributions of *nix with an MTA installed tend to only listen by DEFAULT to the localhost for connections.
So NO as per OpenBSD's claim "Only one remote hole in the default install, in more than 7 years!" see "http://www.openbsd.org/" there is not a "remote root hole for OpenBSD users" in the default install.
If you have opened up Sendmail to the outside world it's YOUR responsibility to make sure its kept up to date and secure.
.
Re:Cross Upgrade to QMail (Score:2, Informative)
I'm really confused about what you mean by this? Although I've never set it up like this, why can't you simply put maildrop in UserA's .forward and procmail in UserB's .forward?
Re:Cross Upgrade to QMail (Score:4, Informative)
Excuse me, but what the hell are you talking about? Would you care to support this statement in some fashion?
Moderators, shame on you for giving points to this unsupported drivel.
Unbiased readers: compare [cr.yp.to] and contrast [postfix.org] for yourself. Qmail and Postfix are basically feature-equivilant, have roughly comperable performance, and both have stellar security histories. Both have plenty of 3rd-party tools to automate stuff like virtual domains, catch-all users and the like; both integrate nicely into a number of webmail and pop/imap servers.
Deciding between the two is largely a matter of taste: qmail's many small config files versus postfix's few large ones; different methods of handling aliases; etc etc etc.
Re:upgrade FreeBSD 4.7 box? (Score:2, Informative)
Here ya go
V. Solution
Do one of the following:
1) Upgrade your vulnerable system to 4-STABLE; or to the RELENG_5_0, RELENG_4_7, or RELENG_4_6 security branch dated after the correction date (5.0-RELEASE-p4, 4.7-RELEASE-p7, or 4.6.2-RELEASE-p10, respectively).
[NOTE: At the time of this writing, the FreeBSD 4-STABLE branch is labeled `4.8-RC1'.]
2) To patch your present system:
The following patch has been verified to apply to FreeBSD 5.0, 4.7, and 4.6 systems.
a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility.
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/
ftp://ftp.FreeBSD.org/pub/F
b) Execute the following commands as root:
# cd
# patch
# cd
# make obj && make depend && make
# cd
# make obj && make depend && make
# cd
# make obj && make depend && make && make install
3) For i386 systems only, a patched sendmail binary is available. Select the correct binary based on your FreeBSD version and whether or
not you want STARTTLS support. If you want STARTTLS support, you must have the crypto distribution installed.
a) Download the relevant binary from the location below, and verify the detached PGP signature using your PGP utility.
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/
ftp://ftp.
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/
ftp://ft
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/
ftp://ftp.
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/
ftp://ft
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/
ftp://ftp.
ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/
ftp://ft
b) Install the binary. Execute the following commands as root. Note that these examples utilizes the FreeBSD 4.7 crypto binary. Substitute BINARYGZ with the file name which you downloaded in step (a).
# BINARYGZ=/path/to/sendmail-4.7-i386-crypto.bin.gz
# gunzip ${BINARYGZ}
# install -s -o root -g smmsp -m 2555 ${BINARYGZ%.gz}
c) Restart sendmail. Execute the following command as root.
#
Re:OS X (Score:3, Informative)
(You'll have to hit ^c to exit back to the shell; invoking sendmail with -d causes it to wait for a message on stdin to process.)
Re:Cross Upgrade to QMail (Score:1, Informative)
Re:Cross Upgrade to QMail (Score:5, Informative)
One advantage of Postfix over qmail is that Postfix, from the outside, looks a lot more like Sendmail (which, if you're migrating, is a good thing).
There's also a moral angle. Qmail is not Free Software (as djb does not allow publication of modified versions), while Postfix is Free (though GPL-incompatible) Software. Also, Wietse Venema is a better human being (aka not a hypocrite) like djb. For those reasons, I will never use qmail, and I advise all others to not use qmail.
Mandrake advisory (Score:2, Informative)
Re:OS X (Score:4, Informative)
Apple also mentions it on their security updates [apple.com] page.
Re:Wrong. Non-root sendmail is possible. (Score:2, Informative)
Re: Exim as alternative to Sendmail (Score:5, Informative)
The two credible alternatives are Postfix and qmail. Both Postfix and qmail seperate the mail system into a number of fine-grained roles, each with a seperate UID and control over a specific set of resources. Regardless of what vulnerabilities are harbored by the Postfix or qmail code, a bug in either is very unlikely to leave an attacker with root access, or even control over the mail system.
In addition to a coherent architecture that addresses security, both Postfix and qmail were implemented from the ground up to resist textbook attacks like file races, buffer overflows, and metacharacter problems. When I briefly audited Exim [google.com] in 1997, it was immediately clear to me that Exim could not make the same claim.
Re:Cross Upgrade to QMail (Score:4, Informative)