Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Security

CERT: Sendmail Distribution Contained Trojan Horse 335

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.
This discussion has been archived. No new comments can be posted.

CERT: Sendmail Distribution Contained Trojan Horse

Comments Filter:
  • by Anonymous Coward on Tuesday October 08, 2002 @08:29PM (#4413907)
    As long as you could also get the source to the Trojan, as well... right?
    • CERT® Advisory CA-2002-28 Trojan Horse Sendmail Distribution
      Original release date: October 08, 2002
      Last revised: --
      Source: CERT/CC

      A complete revision history is at the end of this file.

      Overview
      The CERT/CC has received confirmation that some copies of the source code for the Sendmail package were modified by an intruder to contain a Trojan horse.

      Sites that employ, redistribute, or mirror the Sendmail package should immediately verify the integrity of their distribution.

      I. Description
      The CERT/CC has received confirmation that some copies of the source code for the Sendmail package have been modified by an intruder to contain a Trojan horse.

      The following files were modified to include the malicious code:

      sendmail.8.12.6.tar.Z
      sendmail.8.12.6.tar.gz

      These files began to appear in downloads from the FTP server ftp.sendmail.org on or around September 28, 2002. The Sendmail development team disabled the compromised FTP server on October 6, 2002 at approximately 22:15 PDT. It does not appear that copies downloaded via HTTP contained the Trojan horse; however, the CERT/CC encourages users who may have downloaded the source code via HTTP during this time period to take the steps outlined in the Solution section as a precautionary measure.

      The Trojan horse versions of Sendmail contain malicious code that is run during the process of building the software. This code forks a process that connects to a fixed remote server on 6667/tcp. This forked process allows the intruder to open a shell running in the context of the user who built the Sendmail software. There is no evidence that the process is persistent after a reboot of the compromised system. However, a subsequent build of the Trojan horse Sendmail package will re-establish the backdoor process.

      II. Impact
      An intruder operating from the remote address specified in the malicious code can gain unauthorized remote access to any host that compiled a version of Sendmail from this Trojan horse version of the source code. The level of access would be that of the user who compiled the source code.

      It is important to understand that the compromise is to the system that is used to build the Sendmail software and not to the systems that run the Sendmail daemon. Because the compromised system creates a tunnel to the intruder-controlled system, the intruder may have a path through network access controls.

      III. Solution
      Obtain an authentic version of Sendmail
      The primary distribution site for Sendmail is

      http://www.sendmail.org/
      Sites that mirror the Sendmail source code are encouraged to verify the integrity of their sources.

      Verify software authenticity
      We strongly encourage sites that recently downloaded a copy of the Sendmail distribution to verify the authenticity of their distribution, regardless of where it was obtained. Furthermore, we encourage users to inspect any and all software that may have been downloaded from the compromised site. Note that it is not sufficient to rely on the timestamps or sizes of the file when trying to determine whether or not you have a copy of the Trojan horse version.

      Verify PGP signatures
      The Sendmail source distribution is cryptographically signed with the following PGP key:

      pub 1024R/678C0A03 2001-12-18 Sendmail Signing Key/2002
      Key fingerprint = 7B 02 F4 AA FC C0 22 DA 47 3E 2A 9A 9B 35 22 45
      The Trojan horse copy did not include an updated PGP signature, so attempts to verify its integrity would have failed. The sendmail.org staff has verified that the Trojan horse copies did indeed fail PGP signature checks.

      Verify MD5 checksums
      In the absence of PGP, you can use the following MD5 checksums to verify the integrity of your Sendmail source code distribution:

      Correct versions:

      73e18ea78b2386b774963c8472cbd309 sendmail.8.12.6.tar.gz
      cebe3fa43731b315908f44889d 9d2137 sendmail.8.12.6.tar.Z
      8b9c78122044f4e4744fc447eea fef34 sendmail.8.12.6.tar.sig

      As a matter of good security practice, the CERT/CC encourages users to verify, whenever possible, the integrity of downloaded software. For more information, see

      http://www.cert.org/incident_notes/IN-2001-06.ht ml
      Employ egress filtering
      Egress filtering manages the flow of traffic as it leaves a network under your administrative control.

      In the case of the Trojan horse Sendmail distribution, employing egress filtering can help prevent systems on your network from connecting to the remote intruder-controlled system. Blocking outbound TCP connections to port 6667 from your network reduces the risk of internal compromised machines communicating with the remote system.

      Build software as an unprivileged user
      Sites are encouraged to build software from source code as an unprivileged, non-root user on the system. This can lessen the immediate impact of Trojan horse software. Compiling software that contains Trojan horses as the root user results in a compromise that is much more difficult to reliably recover from than if the Trojan horse is executed as a normal, unprivileged user on the system.

      Recovering from a system compromise
      If you believe a system under your administrative control has been compromised, please follow the steps outlined in

      Steps for Recovering from a UNIX or NT System Compromise
      Reporting
      The CERT/CC is interested in receiving reports of this activity. If machines under your administrative control are compromised, please send mail to cert@cert.org with the following text included in the subject line: "[CERT#33376]".

      Appendix A. - Vendor Information
      This appendix contains information provided by vendors for this advisory. As vendors report new information to the CERT/CC, we will update this section and note the changes in our revision history. If a particular vendor is not listed below, we have not received their comments.

  • Over a week? (Score:4, Interesting)

    by Anonymous Coward on Tuesday October 08, 2002 @08:30PM (#4413911)

    Many eyes = better security but only when many > 0
  • Checksums (Score:4, Insightful)

    by SexyKellyOsbourne ( 606860 ) on Tuesday October 08, 2002 @08:32PM (#4413923) Journal
    ...and that's why you should actually use those MD5 checksums, instead of unpacking and installing without thinking.
    • Re:Checksums (Score:2, Interesting)

      Thats always a good idea, but I have a deeper question. How do these patches make it into the CVS of these projects and who is doing it?

      I can think of some likely players, namely those who feel that Linux/Unix is a threat to them.

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

    • Re:Checksums (Score:2, Insightful)

      by egg troll ( 515396 )
      Egg Troll wants to know what if the trojaned program was the one with the checksums? MD5s, while an important tool, aren't a cure-all.
    • Do you know that the given MD5 was correct? If the got to the binary, what's to stop them from altering the MD5 given on the website.
      • So don't use MD5. Use PGP or some other signature instead of checksums. The only problem then is getting authentic keys; that's where keyservers and the Web of Trust come in.
      • Re:Checksums (Score:4, Interesting)

        by Anonymous Coward on Tuesday October 08, 2002 @09:05PM (#4414080)
        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.
    • Re:Checksums (Score:5, Informative)

      by delta407 ( 518868 ) <slashdot.lerfjhax@com> on Tuesday October 08, 2002 @08:55PM (#4414041) Homepage
      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 (Score:4, Informative)

        by AntiFreeze ( 31247 ) <antifreeze42&gmail,com> on Tuesday October 08, 2002 @09:06PM (#4414084) Homepage Journal
        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:Checksums (Score:5, Interesting)

          by delta407 ( 518868 ) <slashdot.lerfjhax@com> on Tuesday October 08, 2002 @09:15PM (#4414119) Homepage
          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 [sendmail.org]), 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.
          • Re:Checksums (Score:3, Informative)

            by GigsVT ( 208848 )
            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.

            Red Hat solves this problem by signing all their packages. It's up to Red Hat to assure that the sources aren't trojaned, but they have a big monetary motivation to do so.
          • Re:Checksums (Score:4, Insightful)

            by Tim Browse ( 9263 ) on Wednesday October 09, 2002 @01:07AM (#4415085)
            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

    • ...and that's why you should actually use those MD5 checksums, instead of unpacking and installing without thinking.
      Although I agree that you should check the MD5SUMs of all the software you download, the advisory says that the sendmail FTP server was compromised, the intruders could have easily uploaded new MD5 checksums along with the source code, I am surprised they didn't.
  • by lamj ( 153635 ) <[jasonlam] [at] [flashmail.com]> on Tuesday October 08, 2002 @08:34PM (#4413934)
    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)
    • Gentoo automagically checks MD5 sums when it downloads source packages during installs/updates. Very handy.

      • MD5 checksums are good for detecting corruption - bad downloads, etc. They don't help against tampering, because the Bad Guy can also tamper with the checksum, unless there's some separate distribution method. That's why public-key signatures are so important.
    • Difficult? With GnuPG you can just do a gpg --verify and md5 is just md5sum filename

      You mentioned the real issue: key management. If files from ftp.sendmail.org get infected, then people could probably get a bogus key as well. (Although the sendmail folks verified that the files didn't have an updated signature and wouldn't have validated).

      • by tuffy ( 10202 ) on Tuesday October 08, 2002 @08:53PM (#4414028) Homepage Journal
        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).

        • 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.


          Not only that, but public keys (or even complete keyrings containing public keys for groups of developers) can be obtained from multiple, different sources, all of which in turn are different and ideally independent of where one downloads the source tarball from.

          This means one can obtain a developer's key or keyring from, say, a public key server (or two, or several), some ftp site (preferably a different non-mirror one from the tarball), a purchased CD, or any number of other places, check them against each other (make sure none disagree), and use them to check a download immediately, as well as 5 years from now.

          The cracker would have to not only trojan the tarball, but also break into numerous independent key servers around the globe, numerous ftp sites around the globe, likely numerous web sites as well, and perhaps even various freenet nodes as well (if that is being used to distribute keys as well). And for those who anti up $5 for a CD with developers keys on it, they'd have to intercept the postal service and swap CDs as well (or crack the master CD before it goes to press).

          Good luck. Even the NSA would probably have trouble pulling something like that off.
    • Source Mage [sourcemage.org] (The distro formerly known as Sorcerer) checks MD5 sums on download if they are known. I don't have sendmail installed, so I don't know if it would have caught this one. I think so because the MD5 sum on file for sendmail was created on Aug. 20.
    • Red Hat is good for this...use "rpm -K" to verify packages.
    • FreeBSD [freebsd.org]'s ports system also automatically checks MD5 sums on downloaded files.

      That being said, it certainly isn't inconceivable that the checksums themselves could be tampered with, but it is at the least a further layer of security.
    • rpm -K sendmail-8.12.6-1.src.rpm

      For end users of binary RPMs, RedCarpet (and I presume competing tools like apt-get) automatically check signatures.

      Yes, it is more difficult for tarballs. But I think the theory is that people packaging tarballs have a clue. It really is not that difficult to check sendmail tarballs. Just download that ascii signature file also, and run pgpv. It even runs md5 for you. The only wrinkle is that you have to gunzip the tarball first:

      $ pkg=sendmail.8.12.6.tar
      $ gunzip <$pkg.gz >$pkg
      $ pgpv -v $pkg.sig
      This signature applies to another message
      File to check signature against [sendmail.8.12.6.tar]:
      Good signature made 2002-04-05 19:37 GMT by key:
      1024 bits, Key ID 678C0A03, Created 2001-12-18
      "Sendmail Signing Key/2002 <sendmail@Sendmail.ORG>"

      $ rm $pkg
    • Ximian's Red Carpet does MD5 and GPG verification of packages every time it does an install or an update.

  • Checksums and crypto (Score:5, Informative)

    by bytesmythe ( 58644 ) <bytesmythe@gmail. c o m> on Tuesday October 08, 2002 @08:36PM (#4413945)
    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.

    • I'm not sure I completely understand what you're saying. Here's what I propose (not certain if it's what you're saying or not):

      The author of a package should digitally sign the package he is distributing, and part of that signature should necessarily contain the appropriate MD5 checksum for the package.

      This way, one can easily tell if the package has been tampered with (if the signature does not unencode with the author's public key, or the unencoded checksum is invalid). Of course, the one flaw with this is that there needs to be a way to determine who the author is and grab the author's public key. If the author's identity is stored in the package, then this method is useless. If the author's identity can be found via some central resource (say, a searchable database of projects and their authors on the FSF or GNU websites), then the security of this method is only as strong as the security of that database.

      All in all, food for thought, but no real foolproof way of verifying you're installing untampered binaries.

  • Scary. (Score:5, Interesting)

    by QuantumWeasel ( 606327 ) on Tuesday October 08, 2002 @08:37PM (#4413953)
    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.
  • by domninus.DDR ( 582538 ) <domninus@hotmail.com> on Tuesday October 08, 2002 @08:39PM (#4413957) Homepage
    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?
    • It would be best to sign the MD5 with a PGP signature. They key they use may have also been compromised, but at least that adds another layer to security.

    • 1) They obviously didn't have access to the website, as the HTTP downloads of Sendmail were NOT compromised
      2) It didn't get discovered for a week, so obviously no one used the check sums.
    • by iamplasma ( 189832 ) on Tuesday October 08, 2002 @08:47PM (#4414001) Homepage
      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.
      • by bockman ( 104837 ) on Wednesday October 09, 2002 @02:37AM (#4415307)
        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 ?

    • by mosch ( 204 )
      Well, the solution to that is a distributed checksum, such as is found in the FreeBSD ports system.

      Type cd /usr/ports/mail/sendmail && make install and it then downloads the source, and then checks what it downloaded against an md5 checksum that's kept on your machine before it applies patches and builds.

    • "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?"

      You get the binaries from a mirror to ease the load on the master server and then get the MD5sum (which is just a few bytes) from the master server to verify the binaries you got.

  • by Anonymous Coward on Tuesday October 08, 2002 @08:40PM (#4413962)
    What?! It's not M$? oh.......
  • by eamber ( 121675 ) on Tuesday October 08, 2002 @08:40PM (#4413968) Homepage Journal
    Good thing I use Exchange Server. I've got a tight ship there.
  • by greenskyx ( 609089 ) on Tuesday October 08, 2002 @08:42PM (#4413977)
    That way when you get your software you know who put the security holes in it. It's all part of trustworthy computing... ;-)
  • Sendmail (Score:2, Funny)

    by Anonymous Coward
    Further proof that security through obscurity don't work.
  • Only the FTP... (Score:5, Insightful)

    by OneFix ( 18661 ) on Tuesday October 08, 2002 @08:44PM (#4413989)
    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?
    • by Quixote ( 154172 ) on Tuesday October 08, 2002 @09:39PM (#4414203) Homepage Journal
      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."

      • Actually, GA releases of two Microsoft products for non-english languages shipped with the Klez worm.
      • Re:Only the FTP... (Score:5, Interesting)

        by OneFix ( 18661 ) on Tuesday October 08, 2002 @11:20PM (#4414660)
        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 [mmsdirect.com] 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...
      • 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."

        Um. I can't tell if you're kidding or not, so I'll bite:

        It doesn't matter what kind of computer runs the machine that copies the CDs. The machine that creates the master CD could have a virus, and infect an executable on the CD. I'm sure microsoft has a number of failsafes in order to make sure that this master CD doesn't have a virus on it, but having a unix computer run the duplication machine is not one of those failsafes.
  • Question (Score:3, Interesting)

    by Door-opening Fascist ( 534466 ) <skylar@cs.earlham.edu> on Tuesday October 08, 2002 @08:49PM (#4414009) Homepage
    Is doing a

    # netstat -a | grep 6667

    all that is necessary to see if one has a the open port, or is there more to it than that?
    • Re:Question (Score:3, Informative)

      by jericho4.0 ( 565125 )
      Moderators!! This is on topic!

      I can't say for sure but seeing as the trojans only action is to open the port (doesn't infect anything, can't survive a reboot), it's probably not smart enough to cover it's tracks very well and that would probably show it.

      The solution given in the cert advisory is basicly

      1. 1. reboot
      1. 2. install untrojaned sendmail.
  • Holy crap (Score:2, Interesting)

    by Anonymous Coward
    I actually did a postfix install during that period.

    I considered doing sendmail, but then I remembered how fucking thick the ORA sendmail book is and how complex it is, so I decided, "screw it, let's try postfix, I have never tried it before." If I had gone with sendmail, there would be some serious egg on my face tomorrow morning. We might be running MS exchange within a week if that had happened.

    (Oh yeah, and postfix was pretty easy to set up.)

  • by fliplap ( 113705 ) on Tuesday October 08, 2002 @08:52PM (#4414021) Homepage Journal
    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.
  • No worries! (Score:4, Interesting)

    by Greyfox ( 87712 ) on Tuesday October 08, 2002 @08:52PM (#4414027) Homepage Journal
    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.

    • 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...

      It isn't that complex to do it right, but as we all know, it's the human factors that get you. I'm sure GnuPG has all the functions necessary to implement it, but you need a trusted party with rock solid proceedures to ensure the top of the chain. What do people do for a CA for their signatures?

      As long as you can be certain that: 1) You have the correct public key for the signing authority, and 2) nobody but the signing authority can get access to the corresponding private key. You can do it yourself by generating a key set for your own CA to a floppy and then making signing keys for yourself and your friends from there. You only need the public key to make a certificate, so a friend can email it to you, you get out your floppy and sign with GnuPG, and send the cert back. Keeping your signing keys off-line is a good idea too (if your paranoid, but who can afford not to be with this stuff going on).

      Now, the only point that can be attacked is to compromise the CA's signing certificate (This is the CA's public key, signed by itself). If you squirl away a copy of it and get a new copy from time to time to double check you should be completely safe. You could use a public CA, but the commercial ones tend to charge a lot, so it would be nice to have a cooperative CA that does it on the cheap, but still does it well (Does such a thing exist?). Since someone is obviously getting their jollies by compromising distributions on public ftp servers, I'd be a little careful about setting this up. As long as the root signing key is safe (This is the private key), you can make lots of copies of the root certificate (on differenct servers, of course) and verify them with each other periodically.

      With all of this in place it should be a simple matter to script the verification of signed signatures. I know I'm not the only person who knows how to do this correctly, so perhaps this is already done. If not, it looks like an excellent project for someone wanting to do this stuff.

  • Does any one know (Score:2, Interesting)

    by gorjusborg ( 603799 )
    How long does it take for all the trojan infested code to propagate out of use?

    I wonder how many admins download/install packages, go on vacation (missing all the warnings), and simply never hear of the problem.

    I think it would be interesting to see some statistics on this topic.
  • Hardly news ... (Score:5, Insightful)

    by jc42 ( 318812 ) on Tuesday October 08, 2002 @09:04PM (#4414079) Homepage Journal
    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.
    • by Trogre ( 513942 ) on Tuesday October 08, 2002 @10:15PM (#4414353) Homepage
      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.

  • Ah... (Score:2, Insightful)

    by The Bungi ( 221687 )
    Is this like that script worm that was shipped with the .NET framework in Taiwan or India or something like that earlier this year?

    Hmmm. Except this looks a bit uglier.

    Of course, the headline for that was very different. A bit more, let's say, sensationalistic. Yeah, that's the word I was looking for.

    • This is a different issue altogether as anyone building sendmail from the contaminated source would end up with an infected system.

      The script worm you are referring to was found in an html help file which was a native language translation done by a third party and inadequately checked by MS before mastering the cd. You couldn't get infected by installing .NET from the cd and the particular exploit the script relied on was fairly old -- so any recent version of IE wouldn't have executed the script.

      It just goes to show that there is no such thing as 100% secure. I can be really bad about not checking signatures on source I download before compiling/installing.
  • by alehman ( 41225 ) on Tuesday October 08, 2002 @09:12PM (#4414108)
    How 'bout a quick tutorial from someone who knows pgp or gpg or MD5 on how to use it to figure out if my recent install is trojaned?

    Also, the CERT advisory doesn't give any fixes, it just gives the signatures. It doesn't seem like installing a good version would eliminate the trojan.
    • Oh no, cause that would actually be helpful. Funny how yours is the most relevant question and yet a bunch of stupid MS jokes are modded higher.

      I would mod you higher, but since I modded down Alan Cox I've never had mod points again. He was offtopic though.
  • *yawn* (Score:4, Insightful)

    by comet_11 ( 611321 ) on Tuesday October 08, 2002 @09:19PM (#4414129)
    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.
  • Big apps like sendmail and exchange that wants to do everything are always going to be bug ridden. Thats mainly because the code is so big that its impossible to have a complete picture of how everything interacts. Installing and hiding trojans in a large CVS tree is easier too than in a small tree. Learn from MS on this one. Do everything halfbad or one thing excellent.

    Putting software on secure servers or better to put them on a community server would be nice. I can understand that coders dont want to tinker on their servers when they want to code but why not get some help?

  • qmail anyone? :) (Score:2, Interesting)

    by portege00 ( 110414 )

    I realize that qmail wouldn't solve the problem of modified tarballs that allow trojans to come alive during builds (that's what md5s are for), but if you're really worried about security you'd probably be using qmail [cr.yp.to] anyway. If you can prove me, the author, and everyone else who has a qmail fetish wrong, there's a prize in it for you.


    After the number of open e-mail relays I've had to deal with, sendmail leaves a sour taste in my mouth. Using the blacklist that has no real regulation on it doesn't seem to help, either. Closing a relay makes users upset. Sendmail is a lose-lose situation, and now there's a trojan in it to top it off. Wee!

    • I've preferred qmail for quite some time, but I don't use it at home because it's a pain to install (relative to just tweaking my existing sendmail setup which I've grown to understand). I'd love it see it move into more major acceptance, but the problem is that sendmail is the default for many distros. RedHat doesn't even have a qmail RPM to install.
      • If you're running linux you could check out qinstall:

        obua.org [obua.org]

        They have a script for FreeBSD too but I prefer:

        Matt Simerson's Qmail Toaster

        I've got a couple sites running Qmail, djbdns (tinydns, dnscache, etc), courier, and sqwebmail/squirrelmail and it simply rocks. It is a bit of pain to get installed but the actual configuration of the software itself is so simple it is worth the pain. Bind vs tindydns config files are simply hilarious because the tindydns one is just so damn simple! Qmail is much the same.
    • Re:qmail anyone? :) (Score:4, Informative)

      by Wdomburg ( 141264 ) on Tuesday October 08, 2002 @10:15PM (#4414355)
      >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
  • by archnerd ( 450052 ) <.nonce+slashdot.org. .at. .dfranke.us.> on Tuesday October 08, 2002 @09:52PM (#4414240) Homepage
    Yup, I got slimed, and I'm not an easy person to slime. This dude is the first person ever to get one up on me. But I'll have my revenge. I diffed the malicious source tree with the authentic one and found the malicious code. It looks amazingly innocuous until you base64 decode the shell script :-). His IP address is 66.37.138.99.
    • Yeah, this guy looks pretty mean [66.37.138.99]. Incidentally, unless it's been recently changed, 66.37.138.99 points to spatula.aclue.com:

      Decisionism Inc. (ACLUE2-DOM)
      4260 E. Evans Ave.
      Denver, CO 80222
      US

      Domain Name: ACLUE.COM

      Administrative Contact, Technical Contact:
      Klein, Eli (NCMGTMOSXI) elijah@firstlink.com

      4260 E. Evans Ave.
      Denver, CO 80222
      US
      no phone no fax

      Record expires on 17-Dec-2003.
      Record created on 17-Dec-1998.
      Database last updated on 8-Oct-2002 23:09:51 EDT.

      Domain servers in listed order:

      NS3.FIRSTLINK.COM 66.37.141.4
      DENVER.FIRSTLINK.COM 66.37.143.67

      Any chance this isn't the guy responsible (i.e., Eli had his machine h4x0r3d)? Talk about an ironic choice of domain names.... At least he's running Apache [aclue.com].
  • An intruder operating from the remote address specified in the malicious code can gain unauthorized remote access to any host that compiled a version of Sendmail from this Trojan horse version of the source code. The level of access would be that of the user who compiled [emphasis added] the source code.

    It is important to understand that the compromise is to the system that is used to build the Sendmail software and not to the systems that run the Sendmail daemon. Because the compromised system creates a tunnel to the intruder-controlled system, the intruder may have a path through network access controls.

    I guess that would mean that just downloading the correct sources and recompiling isn't enough to right an infected machine. Does anyone have any details about what specifically this does (and how to get rid of it)? Does it install some binary? Run some daemon created as part of the build process? The advisory doesn't seem to say much (other than point to a generic set of recovery instructions [cert.org], albeit pretty good ones).
  • Md5 checksum is not enough to protect us when the main source is being trojaned.

    Some people recommend PGP - to be more precise, public-key encryption and digital signature. However, we'd get into a similar situation when the public key itself is not from the legitimate owner of the package(impersonating during the process).

    May be we should start introducing PKI(more info [pkiguru.com]) in the distributing of open source packages. However, issuing a CA costs money, which is not very desirable for opensource development.

    I've been heard of some effort in issuing CA for opensource projects. Then again, the costs implied in CA does not mainly lie in the issuing, administrating or distributing the CA, it's the legal liability that we pay for. If there's no legal liability in opensource CA, then we lost the whole point of introducing PKI into the packages distributing process.

    I'm sure people are working on a feasible solution to this problem. We must really do something when more and more people using opensource software.
  • There are actually many solutions to this particular problem (where the distribution site was broken into, and the correct program changed into a Trojaned program).

    A trivial approach is for program distributors to keep on a SEPARATE machine the file that's being distributed, and then periodically send copies up. That way, if a single file is modified, it will get "unmodified". A sophisticated cracker can subvert this, but it takes more effort.

    A trivial approach for users is to wait a number of days between (1) download and (2) getting the MD5 checksum or PGP key. That delay gives the original distributor time to detect a problem. Then, use the MD5 checksum or PGP key to detect if the program is actually the right one.

    These approaches don't solve all attacks, but they do make attacks harder. Clearly, it would be better if PGP keys were distributed either via some trusted path and/or via ahead-of-time (like the ports system does).

    Perhaps my Easy email security approach [dwheeler.com] could be implemented, which would also make it easy to quickly get keys. In my approach, I propose using DNSSEC (DNS security) to get a trusted path to a remote LDAP server, and then use LDAP to retrieve key. That way, you don't need to pay big bucks for a separate certificate... you can get your certificate when you register for your domain name, and then manage all the other keys yourself.

  • by Anenga ( 529854 ) on Tuesday October 08, 2002 @10:34PM (#4414448)
    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. [rsasecurity.com]".

    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 [bitzi.com] (the Metadata/Hash catalog) has also recommended to the Gnutella Developer Forum not to use MD5 [yahoo.com], 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)
  • by friscolr ( 124774 ) on Tuesday October 08, 2002 @11:07PM (#4414599) Homepage
    for those of you who read /. instead of the mailing lists for your OpenBSD news, OpenBSD is not affected [theaimsgroup.com]

    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 (Score:5, Informative)

    by netmask ( 8001 ) on Tuesday October 08, 2002 @11:11PM (#4414611)
    I have made the backdoor'd sendmail code available at http://www.enzotech.net/files/sm.backdoor.patch [enzotech.net]and the base64 portion is decoded at http://www.enzotech.net/files/sm.backdoor.base64.t xt [enzotech.net]
    This was diff'd from a previously downloaded tar ball that we were using for analysis of another bug.
  • by billstewart ( 78916 ) on Wednesday October 09, 2002 @12:48AM (#4415023) Journal
    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.
  • by thogard ( 43403 ) on Wednesday October 09, 2002 @02:19AM (#4415268) Homepage
    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.

Those who can't write, write manuals.

Working...