Slashdot Mirror
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.
As long as you could also get the source to the Trojan, as well... right?
PGP signing is a good way to prevent trojaned software like this case. But I think the process to verify the software is too complicated and not easy for all users to use. Let me ask you this, when is the last time you checked the hash or PGP signature after you download a software?
For most people, never.... It would be great if we have automatic download tools to check signature as well (obviously, we need standard for storing the signature as well)
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.
bytesmythe
Hypocrisy is the resin that holds the plywood of society together.
-- Scott Meyer
It's been a long time since I installed sendmail or inn or bind from sources. At some point I stopped checking MD5 signatures, and now I trust the major distros to do that for me. I sure hope they're more vigilant than me. And I used to be so paranoid... This is a nasty wake-up call.
everyone says just check sums, but how are these people changing the file? If they can change the tarball on the server than why not change the page to have thier md5?
Good thing I use Exchange Server. I've got a tight ship there.
According to the advisory, it was only the FTP site that was compromised (The HTTP was fine).
So, as for those that are saying it's an Open Source problem, this is just wrong.
There's been alot more closed software distributed with Viri/Trojan Horses. The truth is, this is bound to happen if the public archives are on an unsecured server...I even seem to remember pressed CDs being distributed with trojans.
So, what are they doing to keep this from happening again?
Also can't forget about the black hats and chinese/russian/terrorist groups as well.
Incorrect md5 sums certainly strike terror into my heart.
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.
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.
Let's see, a Trojan Horse is basically defined as an undocumented chunk of code hiding inside a program, which does something that you don't know about or understand.
Sendmail is such a complex beast that, no matter how much you personally know about it, there are always things in there that you don't know about or understand.
So it has always been full or Trojan Horses.
This is the fundamental thing that's wrong with building a hugs program that tries to do everything possible. Pretty much all the other mail tools are better at sendmail in this respect, because they only try to be a mail tool.
Sendmail, OTOH, is an emulator for a rather complex sort of machine language. Some time back, someone demonstrated that it was possible to emulate a Turing machine with a sendmail.cf file. Impressive as this may be technically, it's way overkill for the task, and it shouldn't be any surprise to anyone when problems turn up in sendmail and aren't discoverted for a while.
It's guaranteed that there are others lurking inside that monster.
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
Gentoo neatly gets around this problem by using the source directly, and since a lot of projects list md5sums of the source archives (such as sendmail 8.12.6), Portage can make sure that it gets the correct tarball.
Oh, and by the way:So, Gentoo had the right one on file all along. And, of course, Portage won't unpack files with the wrong md5sum, meaning Gentoo users were completely immune to this.
>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
MD5 Checksums have a higher rate of collisions, both in the wild and artifically. A machine can be built for only around $100k or less which can find collisions in less than 24 hours. Hell, in a few years standard computers could probably generate collisions easily. SHA1 (Simple Hash Algorithm) is a much better alternative over MD5.
The previous version of MD5, MD4, was so flawed it is now considered "broken". "Dobbertin [Dob95] has shown how collisions for the full version of MD4 can be found in under a minute on a typical PC... Clearly, MD4 should now be considered broken.".
SHA1, while of the same family of hashes as MD4 and MD5, remains uncompromised by any research discoveries, and is widely used in many applications requiring the highest levels of security.
Gnutella, the File Sharing Protocol, uses SHA1 over MD5 for the same reasons I state here. A developer of Bitzi (the Metadata/Hash catalog) has also recommended to the Gnutella Developer Forum not to use MD5, but SHA1 instead. Thus, people should be using SHA1 instead of MD5. I've noticed some major websites and companies are using MD5 hash's now, such as Adobe and Roxio. I would recommend to them to change them to SHA1 instead, since Gnutella supports it (and the fact that it is a much more secure and stronger hash algorithm)... and they can use MAGNET URI's to link to the files on Gnutella.
(sorry, I have to get this out of my system)
...
:-)
READ THE ARTICLE AND REALIZE WHAT IS GOING ON!
It says that:
The FTP-server of sendmail.org was compromised.
It doesn't say that:
- somebody commited code to the CVS server.
- nobody reads the commitlog of the CVS server.
It says that:
The sendmail-distribution was trojaned.
It doesn't say that:
- sendmail itself was trojaned
- there are trojans inside sendmail
- qmail/postfix is better because it isn't trojaned.
- exchange is better because the source is closed. It's the distribution which is corrupted, not the software.
It says that:
The correct MD5-checksum is
It doesn't say that:
- with PGP signing it wouldn't be prevented. Security is a process, you need to follow the rules or you are not secure. You should check all checksum/signatures you have, preferable from independant resources (e.g. one from sendmail.com and one from your unix-distribution).
Next time, please read the article and realize what's going on before you post (apologies to the people who actually did
Edwin (yes, the guy from the OpenSSH trojan)
bash$
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.
>Packages like djbdns and qmail make service
/etc/mail/local-host-names, and commenting out "DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')".
/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".
>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
Want mail sent to phil@mydomain.net to go to bob instead?? Simple, add "phil@mydomain.net bob" to
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
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
I download the tarball and MD5s. Then I want to verify the signature. For that I need a public key or something like that of the developer that signed the tarball.Since I never met him, I must resort to download also that from an internet place, probably the same from which I downloaded the source.
Now, what prevents whoever cracked the server and placed the troianed tarballs on it, to also change the public key, so that it matches the couterfeit signed tarball?
At a minimum, one should go to some forum/ML and check the key with a dozen or so other users, choosing the ones that got the key in different places and times.
Or am I missing something ?
Ciao
----
FB