OpenSSH Package Trojaned 574
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.
I'm suprised... (Score:2, Insightful)
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
James
How many people do check the MD5 checksum? (Score:3, Insightful)
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:203.62.158.32 (Score:3, Insightful)
I dunno if thats what this one does though.
Re:203.62.158.32 (Score:2, Insightful)
Re:Trojan (Score:1, Insightful)
It is a trojan, like the article title says. It's a completely independent program that a user is tricked into running on his own box that does something other than that user expects.
Re:How to stop this happening again? (Score:2, Insightful)
Check MD5 sums
make -n
Unplug from the net and log all traffic while you compile, install and test. Check the log.
Don't unpack a tarball within 48 hours of its creation...let someone else find the problems.
Be one of the "many eyes" and actually learn some of the source code.
Re:How many people do check the MD5 checksum? (Score:2, Insightful)
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.
Re:How many people do check the MD5 checksum? (Score:3, Insightful)
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:203.62.158.32 (Score:2, Insightful)
Re:hmmm.... (Score:2, Insightful)
Why not hack the md5 checksums? (Score:2, Insightful)
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.
GnuPG a good idea (Score:2, Insightful)
Not the fault of OpenBSD? (Score:1, Insightful)
If they are the ones managing the box, why aren't they securing it? If they aren't in a position to manage the box, why are they even using it?
Also, nobody has done a report on how the trojan was uploaded, so we can't say for sure it was the fault of the OS. It could have been a sniffed password, or social engineering, or whatever.
These guys do good work, but don't discredit the possibility that they make mistakes themselves once in awhile.
Re:hmmm.... (Score:1, Insightful)
Microsoft does not have policy against code rewrites.
I hate the evil bastards from Redmond more than anybody, but still, don't be absurd: all programmers would prefer not to reinvent the wheel.
How to fix this from the site it's calling (Score:3, Insightful)
yes "A" | nc -p 6667
Then every daemon that connects gets an A right away, and thus dies. End of problem.
Re:Open Source PKI Needed? (Score:3, Insightful)
As far as trojaning individual
Every time this comes up on debian-devel the end result is a classic example of "the best is the enemy of the good". The suggestions for minimal signing of anything (say, having the process that creates the Packages file sign it) are always rejected because they wouldn't address the whole problem. (What if master.debian.org were hacked?) Unfortunately, no one can ever come up with an acceptable consensus definition on what the whole problem actually is, so nothing ever comes close to being implemented.
public key authentication (Score:2, Insightful)
Trolling for karma, eh? (Score:4, Insightful)
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.
Where are the public keys? (Score:2, Insightful)
sign the package and then make the public key available
from various other trustworthy sources (three, at least).
Red Hat does this *right*:
http://www.redhat.com/solutions/security/news/p
Both the openssh and openssl people have to make pages like
the one above. If such pages do exists please pretty please
post them here because I haven't seen them. Where are the
"official" openssh and openssl public keys? They are not
mentioned anywhere on either sites' pages!
[1] The definition of "trustworthy" is not trivial. Personally,
a public key found on both the Red Hat site *and* a
box-wrapped CD qualifies. YMMV.
Bad news and Good news (Score:2, Insightful)
I don't think these bugs are symptoms of a systemic problem.
This trojan disturbs me a bit more than those bugs buried in thousands of lines of code. I guess I expect the OpenBSD guys to be good sysadmins, since, well, it just seems like something that should be their bag, baby. And maybe some will disagree with me, but I think that securely adminning a box is easier than writing secure code. (Maybe I'm just prejudiced because I'm a programmer. ;-)
If a trojan got onto OpenBSD's own FTP server, it means that somebody fucked up. Maybe they're not keeping their box up-to-date with the latest fixes. (And it looks like they're not "eating their own dog food," and eating Sun dog food instead. That is ridiculous.) Or maybe, worst of all, some black hat knows about a hole that nobody else knows about. I don't know; I just know I really don't like this. I hope they get on the ball, regarding their unsecure server, muy pronto.
There is a good side to all this, though. I actually give money to OpenBSD (not a lot, but it's something) because I want somebody out there doing OS and OS-related stuff, to be over-the-top paranoid, and I think OpenBSD is the right team (I guess they've got the best slogans). I selfishly want more secure tools to get into circulation, so that I can be among those who use them. And from that perspective, this incident is a fscking godsend, because I think it might result in people starting to adopt some better habits, which will also require some better tools and social networks:
The solution to this trojan problem is not for people to start checking the MD5 sum on their tarballs. If you can't trust an FTP server to give you an unaltered file, then you can't trust a web server to give you a web page with an unaltered MD5 sum. Surely this is common sense?
The real solution is digital signatures (i.e. an MD5 sum encrypted with a private key). And for that to really work, we're going to have to build up a web of trust, so that people will know whether or not they really have a publisher's public key, or an imposter's. Maybe this will get us a little closer to the day when I can encrypt every email I send, and have to decrypt ever email I receive, except for the spam which gets thrown away automatically since it's the only thing that isn't signed by someone accountable.
It is hard to get people to use GPG. Real hard. Try convincing a friend (I mean a geeky friend; non-geeks are impossible) to use it, or try to organize a signing party sometime. I don't know why there's so much resistance and apathy, but it's there. We need all the help we can get, and today we got some.
Re:What else is modified? (Score:2, Insightful)
I don't care how fancy the mechanism is to catch this kind of thing. All fine and well.
How did the trojan get into the code in the first place? Are we to assume there's no oversight in code submissions for a package as critical as OpenSSH?
In any commercial entity where a problem like this was uncovered, there would be a thorough audit of the submission path in process. Perhaps there is in this case as well. But why is nobody even discussing it??
Re:Gentoo is Good to Go (Score:3, Insightful)
why now? this whole episode seems to be a good example of the current system working well... tarball trojaned, ports system detects md5 mismatch, no compromise, no problem.
Re:Does this during the "make"? (Score:2, Insightful)
Of course, this assumes that netstat and pstree haven't been replaced with compromised versions.