CERT: Sendmail Distribution Contained Trojan Horse

Scoria writes "According to a CERT advisory published this afternoon, the public distribution of Sendmail 8.12.6 contained a trojan horse from September 28 to October 6. For more detailed information, please consult advisory CA-2002-28." This sounds very much like what happened to OpenSSH.

Comments

Checksums and crypto

[bytesmythe]

This is a good reason to compare the MD5 checksum of anything you download, source or binary, to what the author says it should be, especially if you downloaded from a mirror. Better yet, the author could use GnuPG and sign the code with his/her private key. Since only his/her public key can decrypt it, you know that the code has very likely not been tampered with.

Re:check sums blah blah

[iamplasma]

Yes, but if you read the full article, the source was also PGP signed, specifically so that tampering could be detected. Short of a miracle, it would be impossible for any cracker to fake a PGP signature, as they wouldn't have the required private key. So if you checked that (as it was specifically intended for), then you pick it up, and I expect that may quite possibly have been how it was detected.

Upgrading Sendmail isn't Enough

[fliplap]

After reading the posting we'll note this is VERY similar to the OpenSSH trojan. The trojan doesn't wind up in the sendmail binary but is actually created during the build process.

So more than just checking the MD5sums of things you download you need to watch who you compile as, since the trojan will have the privledges of whoever compiled sendmail. This isn't exactly the most sly trojan either, it is quite blatent about how it creates a tunnel to a specified target, this can also help the intruder avoid firewall rules and detection.

If you find you've been affected by the trojan you would be wise to reinstall the system from known clean code since the intruder may have already created other backdoors from themself.

Re:Checksums

[delta407]

Gentoo Linux validates checksums on every package before unpacking; doing this pedantically prevented the BitchX trojan as well as many other things.

Just another plus for the distro, I suppose.

Re:Checksums

[AntiFreeze]

apt-get also validates MD5 checksums before installing a package. Very helpful, but of course, if someone can modify the binary that is getting distributed, what would stop them from modifying the checksum?

Of course, it would certainlly be funny if all the modified binary did was, in addition to the normal functionality of the program, also told you that you should verify the relevant checksums before installing.

Re:Over a week?

[Wdomburg]

>What amazes me is I wasn't even aware anyone
>really used Sendmail anymore.

What amazed me is I wasn't even aware anyone really used Unix anymore. Man, look at all the security holes in *that* software's history.

Sendmail hasn't had a remote exploit in over two years. Named has had a single advisory posted against it (a DoS) since the 9.x series was released.

Matt

Re:qmail anyone? :)

[Wdomburg]

>After the number of open e-mail relays I've had to
>deal with, sendmail leaves a sour taste in my
>mouth.

Sendmail hasn't allowed relaying at all for about five years unless you explicitely turn it on. In otherwords, blame site admins, not Sendmail.

Matt

OpenBSD not affected:

[friscolr]

for those of you who read /. instead of the mailing lists for your OpenBSD news, OpenBSD is not affected

From: Todd C. Miller
To: mr grip
Cc: misc@
Subject: Re: sendmail trojan - were stable or current affected?

In message so spake "mr grip" (jhonold):

> does anybody know if either tree in the last couple months had trojaned code
> in it, exploiting make builders?

Not affected. When I committed sendmail 8.12.6 the tarball I fetched
was not the trojaned one. Even if it had been we probably would
not have been affected since we don't use sendmail's build system
(which is where the trojan was apparently inserted).

- todd

The backdoor code

[netmask]

I have made the backdoor'd sendmail code available at http://www.enzotech.net/files/sm.backdoor.patch and the base64 portion is decoded at http://www.enzotech.net/files/sm.backdoor.base64.t xt
This was diff'd from a previously downloaded tar ball that we were using for analysis of another bug.

Re:Over a week?

[Wdomburg]

>Packages like djbdns and qmail make service
>configuration trivial, as it should be.

It really depends on what you're doing with them.

First off, installing either usually involves compiling from source, due to the restrictive licensing.

The software also isn't built to start under native Unix facilities like init or xinetd, so you either need to deal with installing and configuring ucspi and tcpserver, or hacking the source.

The lack of standards support in qmail also ends up requiring patching in a lot of common configurations, further complicating things. And honestly, configuring qmail isn't exactly a dream - permissions issues are easy to miss, a lot of configuration data requires compilation to a binary format, and configuration data is spread across a fairly large number of files and is hardly in the most intuitive of formats, e.g.:

+foo.com-:foo.com:500:500:/domains/foo.com:-::

Djbdns can either be very easy (simple case) or a pain in the ass.

For starters, there are a lot of standards it doesn't bother starting (IXFR, NOTIFY, TSIG, DNSSEC, etc). So interoperability with other servers is at best suboptimal.

Even if you're going to run a pure djbdns environment, there's no built in facility to transfer zone data, so you also need to either install and configure the axfr-dns program or install and configure rsync and ssh or some other method of copying the zone data to the remote server. In either case the propogation isn't automatic, so you'll probably want to write your own scripts to automate this.

Doing split-dns is a lot less intuitive than in BIND, in my opinion. You can add location tags to entries in the database, but the format only allows one per entry, so if you have different location definitions, you need to add the data multiple times (or store your data in a different format and process it into what tinydns-data expects). And those location tags are limited to only two characters, which prevents any meaningful name.

>Last time I checked you need to devote some
>serious time and brain power to properly setting
>up sendmail.

When did you last check? The mid-ninties?

Configuring Sendmail since the switch to m4 files is *trivial* for most setups.

What's even better is that, since Sendmail is under a permissive license, virtually all versions of Unix offer it by default, pre-installed and with a basic configuration.

For example, if you're doing a single domain setup the extent of your configuration on Red Hat would be adding your domain name to the /etc/mail/local-host-names, and commenting out "DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')".

Want mail sent to phil@mydomain.net to go to bob instead?? Simple, add "phil@mydomain.net bob" to /etc/mail/virtuserstable. Want to send all the mail in the domain? Change it to "@mydomain.net". Want to create dummy accounts named mydomain-USERNAME? Make the line "@mydomain.net mydomain-%1".

And on Red Hat you don't even have to deal with compiling the database files, since the init scripts do it for you. Just run "/sbin/service sendmail restart".

Matt

Why Mail Shouldn't Run As Root!

[billstewart]

Sigh. Yet another set of exploits that are far worse because people run their mail systems as root. It's just not necessary - the System V side of the world hasn't done this in decades. Sendmail comes with a bunch of mechanisms to make it run as a user most of the time, but that just means you need to exploit it fast and hard :-) Here are some of the reasons people run mail systems as root

• Too much embedded base to fix. Yes, that sendmail. There are competing mailers - postfix, qmail, smtpd, etc.
  
• Delivering mail to users' mailboxes. The System V world handles this with group permissions, by making the mailboxes group mail and running the mail delivery system as group mail instead of user root. Works fine.
  
• Port 25 "secure" because root-only. The naive implementation is to run the smtp daemon as root to access it; the other naive implementation is to use inetd or its relatives to open the port but run the application as a user. A much better solution would be to modify the kernel to do a least-privilege approach, letting some other approved user own the port, though that's got obvious portability issues for applications that want to run on multiple flavors of Unix. But it ought to be done.
  
• Running user-provided filters on incoming mail, e.g. procmail or vacation-mail senders. This is a bit harder - it's easy enough to implement a mail-user vacation-mail daemon, but doing a procmail that doesn't need to be root but doesn't let arbitrary users abuse it takes a bit of work; the filter could easily require group root privileges to run, and only really needs to acquire the recipient's userid if it's accessing private directories - that's inherently unsafe (because a bad procmail script could let people attack you), but if you want to do it, it shouldn't be too hard to set the filter to r-sr-x--- jruser mail or something like that. Better to have the user set up directories that group-mail can write to.