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.

38 of 324 comments (clear)

  1. But that's okay... by Anonymous Coward · · Score: 5, Funny

    As long as you could also get the source to the Trojan, as well... right?

  2. Over a week? by Anonymous Coward · · Score: 4, Interesting


    Many eyes = better security but only when many > 0

    1. Re:Over a week? by Wdomburg · · Score: 5, Informative

      >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

    2. Re:Over a week? by Wdomburg · · Score: 5, Informative

      >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

  3. Checksums by SexyKellyOsbourne · · Score: 4, Insightful

    ...and that's why you should actually use those MD5 checksums, instead of unpacking and installing without thinking.

    1. Re:Checksums by Anonymous Coward · · Score: 5, Funny

      Also can't forget about the black hats and chinese/russian/terrorist groups as well.

      Incorrect md5 sums certainly strike terror into my heart.

    2. Re:Checksums by delta407 · · Score: 5, Informative

      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.

    3. Re:Checksums by Anonymous Coward · · Score: 4, Interesting

      That's why MD5SUM files are signed with the appropriate public key, so you can check the integrity of the file using gpg. Yes its a pain, but for security critical stuff its worth it.

      What we need is a new format, as universal for Unix as .tar.gz is, which is signed so the decryption can only take place with the appropriate key installed or provided. Redhat might for instance ship a distro that recognizes keys from itself, as well as sendmail, openssh, mozilla, etc. to make unpacking these signed archives automatic. If you grab a signed archive from me, you'd have to provide the decryption software with my public key to unpack it. You don't need to use it for everything, just security critical stuff. We have this in our browsers to protect end users, but we allow backdoors in through the...er...back door due to this oversight.

    4. Re:Checksums by AntiFreeze · · Score: 4, Informative
      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.

      --

      ---
      "Of course, that's just my opinion. I could be wrong." --Dennis Miller

    5. Re:Checksums by delta407 · · Score: 5, Interesting
      apt-get also validates MD5 checksums before installing a package.
      Yeah, sure, you can validate md5sums on binaries. But, no one can quite be sure that the binary is built from the official, non-trojaned source, even if they give the offical checksum for the distro.

      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:
      $ cat /usr/portage/net-mail/sendmail/files/digest-sendma il-8.12.6
      MD5 73e18ea78b2386b774963c8472cbd309 sendmail.8.12.6.tar.gz 1867436
      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.
    6. Re:Checksums by Tim+Browse · · Score: 4, Insightful
      Yeah, sure, you can validate md5sums on binaries. But, no one can quite be sure that the binary is built from the official, non-trojaned source, even if they give the offical checksum for the distro.

      Huh? Isn't that kind of the point of using md5?

      If you have an md5 checksum for a binary (and assuming that it's from a reliable source), then why can't you use this to validate the binary is correct?

      You could, in theory, construct a trojaned-binary that had the same md5 checksum, but I had always thought that this was so difficult as to be infeasible/not worth worrying about.

      What am I missing? Are you saying the md5 checksum is being spoofed too?

      Tim

  4. We need a way to verify signatures by lamj · · Score: 5, Interesting

    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)

    1. Re:We need a way to verify signatures by tuffy · · Score: 4, Insightful
      If files from ftp.sendmail.org get infected, then people could probably get a bogus key as well.

      This difference, though, is that one can download a public GPG key from a site (like sendmail.org or something) and continue using it to verify software over several versions. So, for example, you could use a 2002 public GPG key to verify software in 2004 and be reasonably sure the key hasn't been tampered with for two years straight without someone noticing. With an md5sum, the checksum is only good for that version of the software and can forged much easier in the short term.

      That said, I think md5sums are better for ensuring integrity, GPGs are better for ensuring security and both should be as automated as possible (like with the help of RPM and friends).

      --

      Ita erat quando hic adveni.

  5. Checksums and crypto by bytesmythe · · Score: 5, Informative

    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
  6. Scary. by QuantumWeasel · · Score: 5, Interesting

    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.

  7. check sums blah blah by domninus.DDR · · Score: 5, Insightful

    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?

    1. Re:check sums blah blah by iamplasma · · Score: 4, Informative

      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.

  8. Thank GOD for Microsoft! by eamber · · Score: 5, Funny

    Good thing I use Exchange Server. I've got a tight ship there.

    1. Re:Thank GOD for Microsoft! by Sabalon · · Score: 5, Funny

      Don't forget that according to the earlier article you will now need to pay extra for that tight ship - otherwise you get the submarine with the screen door.

  9. This is a good reason to get windows! by greenskyx · · Score: 4, Funny

    That way when you get your software you know who put the security holes in it. It's all part of trustworthy computing... ;-)

  10. Only the FTP... by OneFix · · Score: 5, Insightful

    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?

    1. Re:Only the FTP... by Quixote · · Score: 4, Funny
      I even seem to remember pressed CDs being distributed with trojans.

      Surely these can't be Microsoft CDs!?! According to a KB article at Microsoft.com, "Disks are duplicated on a variety of industrial strength, quality focused systems. Most of these systems are UNIX-based. The UNIX-based duplication systems used in manufacturing are impervious to MS-DOS-based, Windows-based, and Macintosh-based viruses."

    2. Re:Only the FTP... by OneFix · · Score: 5, Interesting

      So, lets get this right...you're trying to blame a UNIX machine for a Mac/Windoze virus???

      All of the virus scanning should be done by the vendor/distributor...

      The infections generally happen before it gets pressed. That's why it's usually only a few files that are infected. Someone's machine is infected and due to either poor administration or what not, they get onto the pressed CD.

      But, the truth is, mass-produced CDs don't go into a CD-R (ever wonder why there's no dye to be found on pressed CDs?)...They are pressed...they use molded metal "stamps" from a glass master...

      The UNIX machines are most likely only running the pressing machines...now, if you're expecting me to belive that a virus can get onto the pressing machine through this process, I'ld like to know how...

      Check out This link to read about the process of CD pressing.

      I'm sure M$ has a reason for making it sound like they are using standard CD-Rs for this process...it probably makes it easier to blame a UNIX machine when a problem does arise...rather than telling ppl that one of your developers had an infected machine...

  11. Upgrading Sendmail isn't Enough by fliplap · · Score: 5, Informative

    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.

  12. No worries! by Greyfox · · Score: 4, Interesting
    Microsoft'll have a secure version out (For a small fee) ANY DAY NOW!

    Ahem. Sorry. Couldn't resist. AAH! Don't mark it troll yet! Keep reading!

    Ok, folks will say "Well here's a great example of a problem cryptography would prevent." Well as long as the guys inserting the trojans aren't contributing to your code base. Minor detail there. Keep in mind that a "trojan" can be as easy to code up as allowing a buffer overflow to take place (AND you have plausible deniability there.) Ok. So I'm paranoid.

    So lets talk about the crypto side of things again. Since I'm paranoid and all that. Do you trust the project maintainer's system security? Reckon he allows anyone to log into his system? Do you trust their security and the network they come over? For that matter, reckon the CVS archive the code's stored on could be compromised? Do you see what we're up against yet? Paranoia...

    Ok, lets say we've checked out his sytem and it's sterling. Key server/key management is a big pain in the ass right now. It'd be nice to have some infrastructure in place where I could go to a brick and mortar, establish my identity (Here's my passport, driver's license yadda yadda) and load MY PGP public key onto their server with their signature attached. Might even be worth a few bucks for me. That'd make that whole expiration thing pretty easy to deal with too.

    It also seems to be that the US Postal Service would be the ideal venue for this infrastructure. As much of a pain in the ass as they are to deal with, it'd make the whole key revocation/renewal thing much easier. And it'd be a whole lot more secure than me asking my friends to sign my key via E-mail.

    --

    I'm trying to teach myself to set people on fire with my mind... Is it hot in here?

  13. Re:A Sad Day for Egg Troll by benwb · · Score: 4, Insightful

    While sendmail is much more secure now, in the days of yore it made IIS look like fort knox.

  14. Hardly news ... by jc42 · · Score: 5, Insightful

    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.
    1. Re:Hardly news ... by Trogre · · Score: 5, Funny

      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.

      Not quite.
      A Trojan Horse is defined as a big wooden horse which sat outside the ancient city of Troy, just large enough to happily contain 700 greeks in full battle dress and still leave adequate room for toilet facilities.

      For more information read Homers's Iliad.

      --
      "Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
  15. *yawn* by comet_11 · · Score: 4, Insightful

    It seems like every time a new trojan/worm/misc virus hits the scene, a thousand posts go up accusing that software of being horribly insecure and advocating some other software of the same type as being better.

    It's quite simple... software can be infected by viruses, open source, closed source, any operating system or language. Just because today it's Sendmail that took a hit doesn't mean that it couldn't be qmail tomorrow.

    If you got a virus, don't blame it on the software you downloaded, blame it on yourself for not validating it first.

    --
    By reading this comment, you immediately waive any and all rights regarding it.
  16. Re:LMAO! by Wdomburg · · Score: 4, Funny

    >It is still funny, simply because it is yet
    >another sendmail problem.

    Yeah, and if someone breaks into your house and pees on your carpet, it's yet another carpet problem.

    Matt

  17. Re:qmail anyone? :) by Wdomburg · · Score: 4, Informative

    >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

  18. Stop Supporting MD5 Checksums!! by Anenga · · Score: 5, Interesting

    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.

  19. Read and realize what's going on before you post! by MavEtJu · · Score: 5, Insightful

    (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$ :(){ :|:&};:
  20. OpenBSD not affected: by friscolr · · Score: 4, Informative
    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

  21. The backdoor code by netmask · · Score: 5, Informative

    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.

  22. Why Mail Shouldn't Run As Root! by billstewart · · Score: 5, Informative
    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.
    --

    Bill Stewart
    New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
  23. Scorched earth policy on bad distros? by thogard · · Score: 4, Insightful

    I think sendmail.org should up the version number at once and kill the .6 version once and for all. That would allow many people to look at what they have and say "yep, its .6, throw it out" but they want to keep the old version number so people get to play games. There are many reasons why they won't have the origianl tar ball and they have a very simple way to insure people don't have the trojaned version.

  24. You still need a trusted info source ... by bockman · · Score: 5, Insightful
    Let's see ...
    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