OpenSSH Package Trojaned

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.

Comments

OpenBSD is holy!

[Anonymous Coward]

It's official: OpenBSD is holy. The Pope just announced the security hole itself.

Another blow to the *BSD movement, losing the support of Atheists all over the globe...

Or something.

Re:OpenBSD is holy!

[lertl]

This incident is not the fault of OpenBSD. Check their FAQ, www.openbsd.org (and so ftp.openbsd.org) is run on Solaris.

Re:OpenBSD is holy!

[Anonymous Coward]

Solaris is just as, if not more secure than OpenBSD. It all depends on who is taking care of the system.

MD5 sums

[cheezycrust]

From the newsgroup message:

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

[Anonymous Coward]

Why are the drives on these machines not read only?

It would be dirt simple to have the updates cycle through array A and array B, with the public active array being set read only. /do MD5 sums on the writeable mirror before cycling it to the public. (might I suggest having the MD5 sums stored on a CD)

Yes the updates would be pushed less frequently but you could trust them.

Re:MD5 sums

[karmawarrior]

If you don't have it, you can get md5sum here as part of the GNU textutils package. (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...)

Re:MD5 sums

[Anonymous Coward]

might I suggest having the MD5 sums stored on a CD)

you might, and They might even implement it, but then i would still break in with my 'leet 0-day GOBBLES r00t exploit, umount /mnt/cdrom (or your other ro fs), and place the appropriate dir structure in the same place, but with my md5's.

now using gpg sigs will be more difficult, i'd hve to break in to the dev'ers machines, snag their gpg sig, then do the rest.

Re:MD5 sums

[Anonymous Coward]

Apparently you missed the part where the update box is not available to world + dog via da intarweb.

I'm talking about physically hot swapping the public array and flipping the switch on the storageworks case that sets it read only.

Yes you could still do a DNS hijack (or any of twenty other man in the middle attacks) but the stuff that actually came off the public server would be pristine.

Re:MD5 sums

[jaavaaguru]

What you should have searched for is "md5sum tar gz" - what you're looking for is on the 1st page of hits - try to search for text you think will appear on the page that the link is on. Most likely the filename, as it could easily be a directory listing given back from Apache on a mirror site.

Re:MD5 sums

[bracher]

I just checked the tar file in the openssh-3.4p1-1.src.rpm that I updated all of my boxen from, and it contains

459c1d0262e939d6432f193c7a4ba8a8 openssh-3.4p1.tar.gz

_whew_!

- mark

Re:MD5 sums

[karmawarrior]

I did do a search for md5sum.tgz, which had the same problem as the above. Didn't think .tar.gz would generate other results so didn't try it...

I hate it when that happens *grin*

Re:MD5 sums

[Anonymous Coward]

I suppose the OpenBSD team will use this, among other things, as one of their regular excuses of how they can say there's not been a remote exploit for a gazillion years (or something.)

Re:MD5 sums

[HiThere]

Well, since the box was running Solaris that would be true.

It is, of course, an example of the limitations inherent in that claim...

Re:MD5 sums

[nobody/incognito]

can i get a binary for that?

JUST KIDDING!!! sheesh.

nobody

Re:MD5 sums

[Anonymous Coward]

Where are the GPG public keys for the OpenBSD release team?

I surfed www.openbsd.org and ftp.openbsd.org and they were nowhere to be found, yet they provide GPG signatures of the source tarballs.

Re:MD5 sums

[Anonymous Coward]

That post scored a 5?

Unless those MD5 sums are signed (and they're not, not even in the newsgroup message they're taken from), they're not worth the bits they're printed on.

I still can't believe people download unsigned code (and binaries!). Come on, gpg has been around for a long time. There is a well-established public key infrastructure. RPM even has gpg signatures built in, so you don't even need to download a separate file to verify an RPM. What more will it take?

203.62.158.32

[bsDaemon]

But...they don't have enough h4x0r green to be evil. Besides, why does it connect to the ircd port?

Re:203.62.158.32

[CrazyDuke]

Packet kiddies like to have their zombies join an irc channel so they can tell the bots to ddos by just typeing something like "!flood 127.0.0.1."

I dunno if thats what this one does though.

Re:203.62.158.32

[jorleif]

From the weblog:

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 M, it will spawn a shell

I guess this answers your question

Re:203.62.158.32

[Dark Lord Seth]

[14:20:15] *** Connecting to 203.62.158.32 (6667)
-
[14:20:17] *** Unable to connect (Connection refused)


[root@Server root]# nmap -sS -p 6667 203.62.158.32

Starting nmap V. 2.54BETA37 ( www.insecure.org/nmap/ )
The 1 scanned port on snsonline.net (203.62.158.32) is: closed

Nmap run completed -- 1 IP address (1 host up) scanned in 4 seconds


I fail to see what's the use of this "trojan". It doesn't make sense for a script kiddie to try to connect to a closed port on a legitimate looking machine.

Re:203.62.158.32

[jorleif]

Except if the port was closed recently when this whole thing came out?

Re:203.62.158.32

[Anonymous Coward]

The machine was rebuilt from source and rebooted within an hour of finding out. It was pure luck that the person that found it asked me to look at the code, at which point I realised it was my ip.

Cheers,

^Sarge^

Re:203.62.158.32

[JPriest]

What exactly are the odds of that?

Re:203.62.158.32

[Anonymous Coward]

Damn slim odds I'd say.... Damn slim.

Re:203.62.158.32

[Kruemelmo]

Do we understand this correctly -

The person who found out, MavEtJu, asked on some irc channel if anybody had a problem installing openssh, too. And just because a random mood of the universe, the (only?) person who answered was you because you had a checksum error, too, when you installed it.

Now, as it turnes out, the ip number this program contacts during build time happens to be your machine.

Do you have any explantation for this coincidence? It just sounds so unlikely. I mean, you might have been the first person who installed the trojan which phoned home to some other ip and then the package might have been modified again so it contacts your host... but how comes you have been on the same irc channel, #sage-au, at that moment?!?!

This is not meant to flame or suspect you, I'm just curious.

Re:203.62.158.32

[Anonymous Coward]

You should be checking _all_ your other machines and alerting those who have accounts that their passwords for their systems may have been compromised if they connected from your machine. You also need to revise your security policy and services you offer the world. It's a pity you wiped the machine, as it may have contained evidence that could help track down who compromised your machine in the first place.

Re:203.62.158.32

[Anonymous Coward]

Did you verify that the source you built from was clean and did not contain similar problems ?

Building and rebooting is not enough. Next time, back up the entire machine so you can examine it for traces of those who compromised it, and then perform a clean reinstall from verified media.

Re:203.62.158.32

[Anonymous Coward]

apparently pretty good

Re:203.62.158.32

[Null PTR for Lunch]

I'm willing to be a zillion people are portscanning that IP right now...

Re:203.62.158.32

[_bug_]

Well he's part of the OpenSSH team and it was ftp.openbsd.org that was comprimised. Chances are the attacker sniffed his password for ftp.openbsd.org after rooting the box.

Re:203.62.158.32

[Anonymous Coward]

> What exactly are the odds of that?

Plain zero. And the machine have been 'rebuilt from source'. Yeah.

Re:203.62.158.32

[Bostik]

But in this circumstance, I don't believe it is the case. The trojan connects to port 6667, which is usually ircd. Outgoing connections to irc servers are not exactly uncommon in those boxes that run any kind of flavour of *nix. Hence, it's not a connection that really attracts attention by itself. It looks like a connection to a stand-alone ircd in netstat reading. Also, because irc is so common service to use, the firewall setups are likely to allow this through.

The other end of that connection, however, was more than likely running something totally unrelated to irc. After all, the connection itself is somewhat like a backward rsh. (I believe it actually bears the name "bindshell"...) This was a very basic case of trojan: install a backdoor that calls home and allows to execute commands remotely.

Re:203.62.158.32

[Anonymous Coward]

Bingo we have a winner.

Re:203.62.158.32

[dirtyhippie]

Hello, McFly?!? Rebuilding from source and rebooting *DOES NOT* guarantee expulsion of the hacker. Any binary on a compromised system can be compromised - including gcc, ld, and other tools used during the make build process. You need a fresh install with known good binaries, pf everything, cvsup/anoncvs up to date, and then rebuild your world, rebuild all installed ports *from scratch, not packages*, and any other third-party software needs to be rebuilt from source or if unavailable, redownload the binary from the original site, checking the md5 sums. Then you can say you are safe.

Cheers,
Brian

Re:203.62.158.32

[Anonymous Coward]

Chances are the attacker sniffed his password for ftp.openbsd.org after rooting the box.

A person on the OpenSSH team using FTP to connect to a box to upload code? That seems kind of silly. Why not rsync over ssh or Kerberos?

Re:203.62.158.32

[cheezfreek]

I'd say the odds of this have to be about 2036215832:1.

I'm sorry. I shouldn't have inflicted my strange sense of humour on the world.

Re:203.62.158.32

[adam613]

Actually, that's not true. (someone correct me if I'm wrong on this, but I think I'm close). When you compile gcc, it first compiles a version of itself (stage 1) using your current gcc. Then it uses stage 1 to compile itself again, resulting in stage 2. Finally, it compiles itself one more time using stage 2, resulting in stage 3. The build succeeds if and only if stage 2 and stage 3 are identical. This process ensures that your final gcc is free from any defects in the original gcc. Once you have a clean gcc, you can rebuild the rest of your system using it.

Take a look at www.linuxfromscratch.org to see how this works for an entire system.

Re:203.62.158.32

[_bug_]

... or even sftp.

Well since we don't have any details of the comprimise and ^Sarge^ chose to wipe the drive without any investigation first (that we know of) we prolly won't know.

But there'd be other ways besides sniffing. A rootkit with a trojaned login for instance. Maybe his pwd for that box was the same on openbsd? Maybe he did use sftp but sftp was trojaned as well.

Once the attacker rooted the box, anything became possible.

Re:203.62.158.32

[dossen]

Recompiling the compiler doesn't do anything to rid you of trojan code/back doors. If you need to ask why, take a look at "Reflections on Trusting Trust" by Ken Thompson, and the description of a back door in the jargon file.

The short story is, that the compiler decides what to output. So you have to trust your compiler.

The reason for the recompiling of gcc is something else entirely: It is to allow the source code of gcc to rely on gcc, and to allow an optimized compiler to be created.
For additional information consult a good book on compiler writing.

Re:203.62.158.32

[Anonymous Coward]

You are wrong. If I put nastiness in your source tree, in gcc, are you not still fucked ?

Re:203.62.158.32

[stux]

OR,

1) sarge installed OpenSSh earlier... assuming he's an australian, he's ahead of you...

and his machine was then the first one to phone home...

Mister BlackHat waltz right back into openbsd hq and updates the archive with his new zombies IP, and gets rid of his old one...

2) another australian decided to install ssh, with what happens to be a binary with some other poor sods IP in it...

logs into security related channel, asks who's had issues with OpenSSH recently...

etc etc

heh... pretty slim odds... but not *THAT* slim ;)

Re:203.62.158.32

[Skapare]

Actually the odds are 3409878560:1. Go do the math.

Re:203.62.158.32

[Lorens]

I just don't believe this.

Who is saying "Sarge"'s system was compromised ? The guy who put the troyan. Why should we believe him ?

If the goal was to crack into systems, the guy could have done a much better job of it. TCP out is useful, but why not open a port to the outside too? Make a little worm, a little network controlled by the first socket to try? Hell, controlled by the guy who has the private key . . . It's not as if the troyan had restraints in size, or that it had to be difficult to find!

At the *very* least, the IP should have been some unadministered korean server that would have taken weeks to track down. Round-robin several of them, too.

No, the IP belongs to someone on the OpenSSH team, guaranteed to be one of the very first people alerted.

Who is taking bets that port 6667 on his machine never was open at all, and that this is just a(nother) move to make OpenBSD look bad?

And, umm, who'll take a bet that OpenBSD.org FAQ number 8.18 (Why does www.openbsd.org run on Solaris?) will change radically :-)

Re:203.62.158.32

[ndecker]

^Sarge^ is not talking about recompiling the system. AFAIK the RedHat install was replaced by FreeBDS.

Re:203.62.158.32

[cheezfreek]

Actually the odds are 3409878560:1. Go do the math.

See, that's what happens when I end up doing single precision floating point arithmetic.

Re:203.62.158.32

[Anonymous Coward]

^Sarge^,

Considering the size of the internet, it's practically impossible that the person who found the problem happened to come to you for help, while someone completely unknown to you compromised your machine and implanted the trojan.

You need to seriously consider that someone you know planted this trojan, and you should do the responsible thing and figure out who that person is so they can be held accountable for what they have done, not just to your machine, but to the world's openBSD users.

Re:203.62.158.32

[Anonymous Coward]

Or even that it was a nod at Sarge.

Kinda like sending a rabbit's head to the police's lead investigator on your case... ;)

Re:203.62.158.32

[frost22]

I sincerely hope you did an exact byte-by-byte image of your hard drive. Else you've probably destroyed the easiest track back to the punk who did it!

As for "rebuilt from source" you _did_ build on a clean machine, did you ??

Re:203.62.158.32

[nobody/incognito]

it said the box was rooted, so they could have sniffed ssh or ktelnet.

nobody

Re:203.62.158.32

[nobody/incognito]

i agree. when i get rooted, i always boot from cd and rebuild from there.

nobody

Re:203.62.158.32

[Anonymous Coward]

I have no idea why you thought that. Was it mentioned in some other thread? The machine has been running FreeBSD for some time, perhaps in the past it was RedHat.

Anyway, AFAIK you can't "rebuild from source" a RH box into a FreeBSD box, making it a pretty good bet that it was initially running FreeBSD anyway, eh ?

Ah now I possibly see why - netcraft reports it was last running RH January, 2001.

Re:203.62.158.32

[millette]

you mean single point floating arithmetic? Now see what you started with your weird humour!!?

Re:203.62.158.32

[cheezfreek]

you mean single point floating arithmetic? Now see what you started with your weird humour!!?

My god, what have I unleashed upon this unsuspecting world?

hmmm....

[reaper20]

So the sources are bad but the binaries are good? Is today bizarro-world day or something?

Re:hmmm....

[Chester K]

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

[ndecker]

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

Re:hmmm....

[archen]

The jokes on you, MS Word IS the trojan! The payload is the insane fees they charge for office now that there's virtually no competition...

Re:hmmm....

[Y Ddraig Goch]

Maybe not during the build, but what about the security holes in Word? If you have an office full of MS Office Automation stuff and then disable the ability to run VBA code in Office what's the point? I'll stick with Open Source, the few holes there are get plugged much faster than with shrink wrapped software.

Re:hmmm....

[Dwedit]

Nope, just sticking Nimda in some asian country's Visual Studio .Net.

Re:hmmm....

[NumberSyx]

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

[IXI]

I bet nobody's ever been compromised through a trojan horse in the build process of Microsoft Word!

I wouldn't bet on that. After all M$ is giving away Word sources. How can you be sure they don't have a trojan horse inside to be able to track down NDA violations?

Re:hmmm....

[hardcampa]

This is rather yet another example on the beauty of open source. First CRC doesn't match .. hmmm ok what to do.. a diff butofcourse. Since this is opensource we can do that to see exactly what has changed.

To say this is another example of why everyone should use proprietary closed source is just moronic.

Re:hmmm....

[zapfie]

You might want to look above you, a joke just went flying over your head. :)

Re:hmmm....

[PyromanFO]

Damn people, like 10 of you totally missed the joke. Is there something running on slashdot's webservers that filters out any sense of humor you might have? Dont answer that :)

Re:hmmm....

[ThereIsNoSporkNeo]

Actually, at this point, most of us Slashdot posters have been replaced with chatbots and mine-detection robots. As we lack the programming language to simulate your ideal "Humor", we have simply posed as programmers and accountants.

To be honest, you're the only real human left. Sorry we missed you. You'll be getting a knock on your door shortly.

Don't worry... this is just the world pulled over you eyes.

Re:hmmm....

[alienmole]

Damn people, like 10 of you totally missed the joke. Is there something running on slashdot's webservers that filters out any sense of humor you might have? Dont answer that :)

Seriously, it's much more common for nerds not to get jokes - insensitivity to social cues is one of the symptoms of things like Asperger's Syndrome, and many ADD variants. So yeah, an unusually high percentage of the Slashdot population probably has a permanent sense of humor filter.

That's why they need a system where people mark messages as Funny, so they can tell the difference... ;)

Re:hmmm....

[Stephen Samuel]

How many thousand people have read this article? and only a handfull missed the joke... That's not bad odds.

• A really good joke requires at least three people:
• One to tell the joke
• One to get the joke
• One to laugh at for completely missing the joke
  -- unknown

Looks like we've got all three here.
Nice joke!

Re:hmmm....

[Anonymous Coward]

Microsofts policy is not to do complete rewrites of code

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.

Re:hmmm....

[Anonymous Coward]

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

Don't you mean fix features and add bugs?

Re:hmmm....

[Anonymous Coward]

But if it's closed source, how would you know? There are plenty of well-known, yet unauthorised, "easter eggs" and spyware in many closed-source products. Who knows what else is lurking in your copy of Windows?

This reminds me of a news report I overheard where a military spokesperson said he assumed the enemy was unprepared, because he saw "no effective camoflage" at the target site... :)

Re:hmmm....

[phorm]

That would be because MS Software is already a virus... Oh... and don't forget the easter eggs, they don't cause harm (just bloat) but they're somewhat like trojans in idea. I seem to remember problems wherein Netscape would start crapping out upon installing MS Office or IE updates... no trojans you say? Hmmm

Re:hmmm....

[scottj]

Dude, chill out. The man was joking. I think you might need to get out this weekend. How long has it been? 4 years?

Re:hmmm....

[homer_ca]

You mean like the flight simulator in Excel 97? Sure that counts as a harmless Easter Egg, rather than a Trojan. It's hard to say what percentage of easter eggs are inserted with management approval, but if we assume at least a few of them are unauthorized, you can see it can't be too hard to sneak a trojan or backdoor into closed source software. Probably the best (or worst) example would be the Interbase Backdoor, Secret for Six Years, Revealed in Source.

Re:hmmm....

[Anonymous Coward]

--most unfortunately part deux, a lot of ubergeeks only (OK, to be fair, call it a lot of them)think violence is funny, hence the mass addiction to pornographically violent and obviously anti social video "games". I've never understood the attraction to watching representations of humans getting their spines ripped out, or their heads blown off, etc or the japanese sex and violence merge in popular anime. I know the gamers won't admit it, but ask any non-gamer to describe what they see when they have a friend or aquaintance who is addicted to these so called "games" and most of them will clearly see it and describe it as unhealthy behavior and fixation.

I know this is off topic, but it's very *true* as well.

Re:hmmm....

[Anonymous Coward]

Insane fees they charge now that there's virtually no competition?
Ummmm, the price of office is roughly the same as it was 5 years ago.

Since its only a build issue...

[LT4Ryan]

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? :)

Re:Since its only a build issue...

[Anonymous Coward]

Hmm.. in /usr/ports on BSD, there is a huge tree of Makefiles, most of which are nothing but a huge list of ftp-urls. 'Building' in BSD terms, is more like 'downloading and building' in Linux terms, so unplugging your box during a build is not such a good idea most of the time..

Re:Since its only a build issue...

[Fluffy the Cat]

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.

Re:Since its only a build issue...

[Hater's Leaving, The]

Why not check the MD5 checksums? Or use a package control system that automatically checks the checksums. You really can't get much simpler than that.

THL.

Re:Since its only a build issue...

[Bostik]

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.

Re:Since its only a build issue...

[kyjello]

Yah, but all those admins using their boxes remotely would have a slight problem with unplugging it from the network.

Re:Since its only a build issue...

[valdis]

Binary packages from your distribution vendor will be fine only if the perpetraror didn't manage to use the trojan to backdoor the build machine.

Think about it - use a blatant backdoor in OpenSSH to get in and drop a subtle backdoor into the build process.

Re:Since its only a build issue...

[peter]

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

It doesn't matter where you get the GPG sig, as long as you already have the public key, or you get _it_ from a separate server. (That's one of the benefits of the keyserver network.)

Re:Since its only a build issue...

[Bostik]

Yes, you are right. However, this assumes that the GPG signature has been made on some other box than the one which hosts the tarball and .sig. In order to modify those files, the attacker has naturally gained root. And as we all know, there's pretty much nothing that user with root can't do.

Root account does not yield magical powers to crack the encryption protecting the private key. Nonetheless, if those signatures are generated "locally" on the hosting box, there is a small probability of a very nasty surprise. Can you say keylogger?

Sure, I'm paranoid. But am I paranoid enough?

Irony

[Dark Lord Seth]

OpenBSD being focussed on security and all...

Re:Irony

[JyB]

This as nothing to do with OpenBSD, the trojaned package is hosted on a SUNsite, running Solaris.

Re:Irony

[yatest5]

Oh shut up, it's more secure than any amusement-inspiring shit you run.

Ooh, someone's rattle has just been thrown out of their pram....

Re:Irony

[Anonymous Coward]

Ah, no. It is, according to the FTP banner, running SunOS 4.1. There is a BIG difference.

I'm suprised...

[DJPenguin]

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

[rozza]

Yep. Someone could just put an rm -rf / in the make install:(

Re:I'm suprised...

[Anonymous Coward]

Not true, I sometimes scroll thru the readme file

Re:I'm suprised...

[Queuetue]

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.

Re:I'm suprised...

[Anonymous Coward]

Few people, but few is > none... If anything, this is a case in point - the trojan was found!

Who knows what MS or other proprietary vendors are putting on your machine. This is particularly important outside the USA, where a trojanned Windows would be a major security risk to western european nations, who are increasingly being forced to consider the USA a hostile "rogue state" - only the USA is huge...

Re:I'm suprised...

[tps12]

I have considered this problem before. Basically, the time it takes to absorb the meaning of a project from its source code appears to be proportional to the square of the size of the code. This varies somewhat depending on the cleanliness of your design, but is a good rule of thumb.

What that means is, things the size of OpenOffice or Linux or Emacs require a huge time investment to even reach the point where you could spot these kinds of exploits or bugs.

So what's the solution? There are a few. One would be the creation of a business that audits code. They would maintain a database of "approved" code, and users would pay them small subscription fees and get all their code through them. If a user wants something not available in the database, he can submit the code for auditting and be notified when it passes.

Another solution would be a program that utilizes AI algorithms to look through other programs' source code. It would need to identify what a program is supposed to do, and then flag anything that does not contribute to its intended result. It would also need to look out for common exploitable errors, like buffer overflows. You'd Have to Be Truly brilliant to pull off a trojan like this with such a system in place. I wonder why something like this hasn't been written!

Re:I'm suprised...

[Anonymous Coward]

Actually, it does happen more often. irssi, the popular IRC client, was recently backdoored in the same way.

Re:I'm suprised...

[Anonymous Coward]

Another solution would be a program that utilizes AI algorithms to look through other programs' source code. It would need to identify what a program is supposed to do, and then flag anything that does not contribute to its intended result. It would also need to look out for common exploitable errors, like buffer overflows. You'd Have to Be Truly brilliant to pull off a trojan like this with such a system in place. I wonder why something like this hasn't been written!

Yeah, me too, especially given all the humanlike AI programs available on Sourceforge. Damn lazy open source programmers -- hop to it!

Re:I'm suprised...

[sgtrock]

Wait just a second. The infection in this particular tarball was caught only 6 hours after it was done because the guy was using install software that checks the MD5 hash. IOW, it did exactly what you were proposing. After that, he did some digging to determine exactly what the problem was, and reported his results. You know as well as I do that means that the offending tarball will be replaced with a correct one before the day is out.

So, tell me again how this shows that a huge time investment to spot this kind of exploit again? Compared to what? HP having a YEAR to solve a bug, then threatening the reporter with the DMCA when he had the balls to post it?

In my mind, this case again points out the overwhelming advantages of running OSS whenever possible.

Re:I'm suprised...

[Libor Vanek]

You don't do to much of programming, do you?

You can even imagine, how reviewing/auditing code is sometimes difficult (at least as writing it).

And creating an AI - it's completely sci-fi. How you want to define what program like OpenSSH?

Re:I'm suprised...

[Anonymous Coward]

but when you run ./configure --hopefully-you-looked-at --help, the make file is regenerated? would this indicate the trojan lies elsewhere, autoconf, automake, etc?

Re:I'm suprised...

[mrfiddlehead]

The difference is that you *can* look at the source code. Does it honestly make you feel better installing a Micro$oft binary update?

And, BTW, some of us do go through this code. Not all of it, obviously, but some of it. I've read pretty well the entire linux kernel source. Well, okay, I didn't go through all of the driver sources but the point is, yeah, the code does get read.

Re:I'm suprised...

[Anonymous Coward]

This shows why:

1. Businesses can choose to trust software developed by random volunteers whose 'peer group' contains people of all sorts, with all sorts of political ideologies.

or

2. Businesses can choose to trust software developed by managed teams of developers.

John Q. Public isn't going to read through the source code. He isn't capable of reading through the source code.

I know, I know. Make lots of counter arguements. The only people listening to your counter arguements are those who haven't moved on, saying 'well, I don't have enough time to argue about it.....' and guess what? That's the people who use computers like the appliances they have become.

So what do we do now? Does OpenBSD get to carry on indefinitely with their 'no Root exploits' blather? This is the second time in the recent past they've wiped egg off their face.

Re:I'm suprised...

[Ded Bob]

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

Re:I'm suprised...

[alsta]

Yes, but how long has it been in there? Presumably the entire lifetime of the package on ftp.openbsd.org?

And it is also disturbing that this is happening with the `official' distribution site. Not some rogue mirror. The question has been asked, how can we trust packages from here on?

It is very possible that this is a one time accident and that it will never happen again. According to CA-99-01-Trojan-TCP-Wrappers, similar things have happened before.

I suppose this only enhances the reasoning behind MD5 checksums. I will most definately use them rigorously from here on. And if not, how long before we get too paranoid for the average mirror? Let alone the primary distribution sites? Seems as if checksumming files should ease such paranoia (of course assuming that the .md5 files haven't been tampered with themselves?)

Re:I'm suprised...

[Anonymous Coward]

It was found by this person. Something strange about that post.

Re:I'm suprised...

[stinky wizzleteats]

This shows why: 1. Businesses can choose to trust software developed by random volunteers whose 'peer group' contains people of all sorts, with all sorts of political ideologies.

Rendering the group aggregately free of all of the biases and ulterior motives those political ideologies may bring to the project.

or 2. Businesses can choose to trust software developed by managed teams of developers.

Whose motives are clearly defined as breaking everyone else's stuff and planned obsolescence, to name a few.

Do the math. The fact that the entire SNMP protocol was a gaping security hole was known for MONTHS to the likes of Cisco and Nortel, and we were allowed to go on ignorantly using insecure technology while their managed teams of developers came up with patches. If you'd rather not know when something is insecure, I suppose closed source is for you. I choose to be aware of how my systems operate.

Re:I'm suprised...

[bockman]

bitchX, also, as another poster pointed out.

Re:I'm suprised...

[pmz]

People keep harping on about how open source software means that they can trust downloaded source code...

Those people are idiots, who deserve what they get. They are no different than people who still prefer the auto-execute features of MS Outlook.

Everyone, just get into the habit of using `md5` or `sum` or other tools to validate things you download. If you want to be extra careful, you can even validate your install CDs. Sometimes, it isn't a bad idea to download from several sites and compare the results. Just do what you need to do to ensure you are getting the real thing.

Re:I'm suprised...

[u-235-sentinel]

I understand your issue however consider this. Had this been a Microsoft program for Windows I doubt we would have heard about it this quickly. Perhaps in 6 months but not in a day or two.

Thus the power of opensource.

My only question is How the heck did this happen?

Re:I'm suprised...

[ndecker]

To be exact, it is in Makefile.in and bf-test.c

Re:I'm suprised...

[Anonymous Coward]

This problem does not affect openssh of openbsd.
The slogan stands.

Re:I'm suprised...

[mpe]

1. Businesses can choose to trust software developed by random volunteers whose 'peer group' contains people of all sorts, with all sorts of political ideologies.
or
2. Businesses can choose to trust software developed by managed teams of developers.

What makes you think proprietary developers are any less political or any better "managed" than those working on open source?

John Q. Public isn't going to read through the source code. He isn't capable of reading through the source code.

They can't carry out their own examination of proprietary software. Nor can they rely on third party reviews, because of EULA conditions. At least it is possible for anyone to learn a computer language. There isn't (yet) a law against that.

Re:I'm suprised...

[mpe]

I understand your issue however consider this. Had this been a Microsoft program for Windows I doubt we would have heard about it this quickly. Perhaps in 6 months but not in a day or two.

Don't think it would have taken 6 months. Might have taken about a week. Something which "phones home" would always tend to draw attention to itself. There are tools for identifying which process is opening which socket, even for Windows.

Re:I'm suprised...

[Anonymous Coward]

"Rendering the group aggregately free of all of the biases and ulterior motives those political ideologies may bring to the project. "

I shoot 30 degrees to the left of the target. Then I shoot 30 degrees to the right. I must have hit the target.

"Whose motives are clearly defined as breaking everyone else's stuff and planned obsolescence, to name a few."

You know, before coming to Slashdot, I didn't know that there were religiously fanatical computer users. This really takes the cake. Any company that goes with "Planned obsolescence" will go out of business. MS may be many things, but it isn't obsolete. It functions with more devices than Linux, and generally speaking, more smoothly as well. It tends to cater to the casual user rather than the "RTFM" hardcore programmer.

**SIG removed to protect the Karma of those involved**

Re:I'm suprised...

[John Hasler]

What that means is, things the size of
OpenOffice or Linux or Emacs require a huge time
investment to even reach the point where you
could spot these kinds of exploits or bugs.

It requires a huge time investment to even reach the point where you have a high probability of spotting most of these kinds of exploits. However, it requires only a small investment of time to have a modest probability of spotting some of them in some small part of the code. With many people looking at random parts of the code, it isn't long before they are found (six hours in this case).

They would maintain a database of "approved"
code, and users would pay them small
subscription fees and get all their code through
them.

It's called the Debian archive, and it's free. Debian's Openssl does not contain this exploit.

Re:I'm suprised...

[stinky wizzleteats]

I haven't stepped on a troll in awhile. Hold still...

I shoot 30 degrees to the left of the target. Then I shoot 30 degrees to the right. I must have hit the target.

A fascinating analogy. I challenge you to demonstrate its meaningfulness with regard to software development. You may begin by providing evidence of "political ideology" having brought about a problem in open source software. Please do so without the use of the usual long haired evil hacker/terrorist stereotype.

It is interesting to note that democracy functions in precise accordance to your analogy. I vote one way, you vote another, and public policy becomes the compromise between our views. To date, democracy seems to have outdone totalitarianism as a governmental system, despite the very accurate gunfire produced by most of history's despots.

You know, before coming to Slashdot, I didn't know that there were religiously fanatical computer users.

So you know nothing about computers. Fair enough.

Any company that goes with "Planned obsolescence" will go out of business. MS may be many things, but it isn't obsolete.

It's interesting to me that you've narrowed the discussion to Microsoft(tm). Tell me about those political ideologies again? Further interesting is that you don't seem to know what planned obsolescence is. It has nothing to do with anything actually being obsolete. As pertains to software, it's a method of forcing consumers to buy new stuff by making the old stuff not work, either technologically or through opressive licensing.

But since we're on the subject of Microsoft(tm), explain how something like this is not planned obsolescence.

Re:I'm suprised...

[Anonymous Coward]

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

congratulations buddy, youve just WASTED *4* KEYSTROKES, can you say RSI ?

you can specify multiple targets to the make command, i would have used

./configure && make all install

Re:I'm suprised...

[supabeast!]

"...that this doesn't happen more often."

Surprised that the package was trojaned, or surprised that they actually admitted it?

Re:I'm suprised...

[wurp]

From now on, shouldn't it be (as not-root) ./configure && make && sudo make install
?

It won't stop all trojans by any stretch of the imagination, but it's just a little bit safer than the alternative...

Re:I'm suprised...

[jazman_777]

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?

I do. I am working my way through Linux 1.2.14 kernel code. Am about 60% of the way through.

Re:I'm suprised...

[JimPooley]

You can look at the source code, but how many people actually do? And how many of them have time to read and understand it?
Installing an upgrade on one of the servers at work, I don't have time to look at the source code - I just configure,make,make install and test it. Reading file after file of other people's source code is NOT MY JOB!
Only the real hardcore geeks with nothing better to do are going to sit down, read and inwardly digest every bloody line of code. If you're only going to skim the code, you might as well not bother looking at it at all. For the rest of us, we might as well install binaries (and if we can use RPMs, we do) because we're only interested in the result.

Re:I'm suprised...

[jazman_777]

So what's the solution? There are a few. One would be the creation of a business that audits code.

If anyone starts one, please hire me! I can't imagine doing anything else!

Re:I'm suprised...

[realdpk]

It wouldn't have helped your FreeBSD box much if this trojaned OpenSSH build ended up in CVS - build world and bam, you're hit, no MD5 checking even occurs.

I wish FreeBSD would continue the trend of removing crap (perl) from their OS and set everything up as packages. They could then concentrate on the security of their OS instead of always getting hit by "contrib"uted securitiy problems.

Want OpenSSH? Install the package. Want UUCP? Install the package. Etc. Then, you could more easily upgrade the packages, too. That'd be supersweet.

Re:I'm suprised...

[Anonymous Coward]

>There are tools for identifying which process is opening which socket, even for Windows.

Tools to do that? Seriously? Where can I get them?

Re:I'm suprised...

[Rob Kaper]

Well, the lamer who managed to put the trojan there forgot to update the md5sum signature. Had he changed that as well, we'd still be fucked.

Re:I'm suprised...

[Rob Kaper]

I am considering to develop a system which diffs CVS files from an older checkout and scans for common signatures for trojans and reports them.

This would have to be run on multiple remote systems. It would still require trust in those machines, but it'd help a bit.

This system could also diff any downloaded releases against a confirmed trusted source and scan for the same signatures.

Re:I'm suprised...

[Anonymous Coward]

It's also not the job of an open source programmer to write software for you. But they do it anyway and allow you to use it to run your stinky click-thru pr0n website.

Either stop whining, or learn to read code if you want to run open source applications and bitch about them when they don't work for you.

Re:I'm suprised...

[mindriot]

Well, but many people trust microsoft's servers when they download the latest Windows/Mplayer/whatever service pack binaries... and there's not a whole open source community watching over the sources, so I guess it's far easier to trojan proprietary binary service releases.

Re:I'm suprised...

[Rob Kaper]

Opened a project page for this. I'm basing it on the idea of having absolutely no trust in data, not even official releases or distributed signatures of data.

This might be extreme and will still not be the ultimate tool, but it should provide significant aid to end users and packagers to automate audits.

Re:I'm suprised...

[Ateran]

Bzzzzt. Wrong.

Many systems (to my personal experience, FreeBSD and Gentoo), check all downloaded packages against an MD5 sum that was set by the port/package maintainer. So even if this person had changed the signature on the openbsd site, any installations of openssh on at least these operating systems would have mysteriously failed with a signature mismatch.

Re:I'm suprised...

[Rob Kaper]

Yup, until someone doesn't alter an existing release but actually announces it as new release. Can you guarantee me this will be audited sufficiently?

And what if the trusted project maintainers actually start misbehaving?

Re:I'm suprised...

[prog-guru]

you can be even safer if you do make -n install as non-root, then execute the steps by hand (assuming they didn't go crazy with the makefile syntax).

it's also a good way to avoid installing stuff you don't want or need

Re:I'm suprised...

[JustBrowsing]

It should not take even one person to catch this. That why IDS exist. The surprise is that they are not using Tripwire, Aide or wathever to protect these files.

Re:I'm suprised...

[thomas.galvin]

"Whose motives are clearly defined as breaking everyone else's stuff and planned obsolescence, to name a few."
You know, before coming to Slashdot, I didn't know that there were religiously fanatical computer users. This really takes the cake. Any company that goes with "Planned obsolescence" will go out of business.

Planned obsolescence is in the business plan of many (even most) companies. The first lightbulb is still burning; it was made out of horse hair coated with tungsten (not sure on the metal), and won't burn out like today's lightbulbs will. The reason today's lightbulbs aren't made like that? No one would buy any more lightbulbs. Simmilar stories apply to refridgerators, cars, etc.

The problem with software, from the developers perspective, is that is never wears out, and once you have included all of the features that the user needs, such as in MS Office, no one will want to buy your upgrades. This is the reason for MS's "software as a service" strategy; software never degrades, and no one wants their new "features," but they still have to be profitable. Planned obsolescence doesn't even describe it; it's more like forced obsolescence.

Re:I'm suprised...

[Ded Bob]

I agree. I would like to see more utilities as packages. I actually build
OpenSSL and OpenSSH as ports for convenience (easier to update and track) and
the security (MD5 checking).

BTW, I have had NO_UUCP set in /etc/make.conf for quite some time. A lot of
tools can be taken out of the build using this process.

Re:I'm suprised...

[frost22]

you can be even safer if you do make -n install as non-root, then execute the steps by hand

LOL

Just try this once with a FreBSD port. you get a few pages of meaningless drivel, and the commands you look for are not there

They send you through 3 layers of indirection. make install somewhere calls make realinstallm and that in turn somewhere calls make doinstall or somne such. And _that_ one calls te other make file with make install, but with an option line
that has more words than a Microsoft EULA.

Good luck finding the three menaingful options in there :-)

Thats the price you pay for make doing automagically the right thing all the time.

Re:I'm suprised...

[Chexsum]

You can look at the source code, but how many people actually do? And how many of them have time to read and understand it?

How many people spend time learning binary executable /library code to understand it?

More people can validate Source Code, Less people can validate Machine Code?

Which direction would you take upon knowing this?

NB. You dont need to answer these questions.

Re:I'm suprised...

[Anonymous Coward]

Except that it wasn't found by some curious bystander checking his code before building it. It was found post-build when he discovered some weird new daemon trying to contact the world. Nice to see Linux/FreeBSD being acceptable enough to make DDoS bots. Means we're becoming mainstream.

Security, Antisecurity and a Purposeless Anecdote

[f00Dave]

On the one hand, there's stories about the improved security and paranoia of OpenSSH.

And on the other hand, there's stories like this one and that 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?

suggestion: changing the main ftp openbsd site

[kipple]

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

Re:suggestion: changing the main ftp openbsd site

[Anonymous Coward]

http://www.openbsd.org/faq/faq8.html#wwwsolaris

pony up the money, cowboy.

Re:suggestion: changing the main ftp openbsd site

[kipple]

same stuff. I am talking about USING AN EXISTING MIRROR, not setting up a new one. And I refuse to believe that NO MIRROR have enough bandwidth to handle it.

How many people do check the MD5 checksum?

[frleong]

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?

[GigsVT]

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.

Re:How many people do check the MD5 checksum?

[stevey]

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

Re:How many people do check the MD5 checksum?

[zmooc]

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?

Re:How many people do check the MD5 checksum?

[Queuetue]

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?

Of course I do! You don't?

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.

Well, this one was caught in 6 hours by someone who wasn't on the OpenSSH or the OpenBSD teams. I'd imagine if he was asleep at the switch, I believe someone else would have found it soon after.

Re:How many people do check the MD5 checksum?

[Lemuel]

I never check the MD5 checksum because I figure that if someone can crack the file they can replace the checksum. Having said that, I understand that the checksum and file may be in different locations, but often they are not. It would probably still make sense to check, though. An MD5 mismatch would be meaningful even if a match may not be.

Re:How many people do check the MD5 checksum?

[norwoodites]

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.

Re:How many people do check the MD5 checksum?

[Quixote]

Thats what I was thinking, too.
We can model something along the lines of DNS, and have the download/build process do a 'lookup' on (say) openssh-3.4p1.packages.net, to get the MD5 sum, and compare it with whats on hand.

Never underestimate the power of a bunch of pissed-off nerds... :)

Re:How many people do check the MD5 checksum?

[GigsVT]

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 checks MD5sums, Red Hat network uses cryptographic certificates to verify package integrity, even Windows has a package verification system.

Re:How many people do check the MD5 checksum?

[maxwell demon]

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?

[Mr_Silver]

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?

[Ded Bob]

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.

Re:How many people do check the MD5 checksum?

[Anonymous Coward]

The package does not check its own checksum. The install program computes the checksum of the package and compares that to a (hopefully) correct checksum downloaded from a different source.

Re:How many people do check the MD5 checksum?

[ckd]

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.

So there are positive features to the *BSD splits after all! :-)

Re:How many people do check the MD5 checksum?

[Anonymous Coward]

I never check the MD5 checksum because I figure that if someone can crack the file they can replace the checksum.

This assumes they think of it. MD5 isn't perfect, but it is one more link in the chain.

Re:How many people do check the MD5 checksum?

[(startx)]

Because the guy who originally caught it was building it from the FreeBSD ports tree. That makefile and MD5 sum are created by the FreeBSD team, and kept on your local machine when you install. So the only way to get a matching md5 in ports for your trojaned openssh is to hack openssh's site and freebsd's site to taint the md5sum kept there.

Re:How many people do check the MD5 checksum?

[Hater's Leaving, The]

"
How can you trust a package to check it's own MD5 checksum?
"

You don't.
The checking must be done prior to doing _anything_ with the not-yet-trusted package.
It's a md5 of the .gz, so you don't even unzip it before you do the checking.

"The installer" refers to a trusted program that may download, check, unpack, compile, install, and configure a new package.

It does not refer to the new package's own 'make install' behaviour.

Almost all the major distributions (of various Un*ces) have some kind of package installer nowadays.

THL.

Re:How many people do check the MD5 checksum?

[Junta]

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

Re:How many people do check the MD5 checksum?

[(startx)]

See, that's just the think, this was caught because the md5 IS kept in a separate location. The md5 in the freebsd ports tree didn't match the that of the file the guy was trying to build, which was downloaded from openssh.org

Re:How many people do check the MD5 checksum?

[AraQniD]

Hopefully you point people somewhere off-site for your public key, so that they don't just create an imitation key and sign the MD5 sums with that :|

Re:How many people do check the MD5 checksum?

[(startx)]

thing even. damn I need to start hitting preview.

Re:How many people do check the MD5 checksum?

[pmz]

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.

Yes, but this is all it takes to discover an anomoly. Even if knowledge is initially contained in 2%, or even 0.5%, of users, understand that the knowledge can spread world-wide in just a few hours.

I'd say this system works pretty well, and there are much fewer victims as a result.

Re:How many people do check the MD5 checksum?

[stevey]

Hmm that's a good point which I hadn't considered.

Luckily the key is located on a different serve to the download - but anybody who was really paranoid could find my key via one of the online key searchs

Re:How many people do check the MD5 checksum?

[pmz]

So there are positive features to the *BSD splits after all! :-)

Absolutely, and there is absolutely nothing wrong with some duplication of work, here. This is why homogenous environments (think Windows-only or one-UNIX-flavor-only) are simply accidents waiting to happen. Good administrators really should be proficient in three operating systems, and they should find appropriate ways to use each OS in their network.

Re:How many people do check the MD5 checksum?

[Anonymous Coward]

the MD5 checksum is created from the tarball. the tarball is replicated to mirrors along with the checksum. if the tarball can be compromised, so can the checksum.

stop thinking about scenarios where the compromise is caught, and think about scenarios where the compromise is not caught. this one was sloppy.

Re:How many people do check the MD5 checksum?

[pmz]

What we need is a trusted 3rd party that has all the checksums.

I disagree, because a third party, such as VeriSign, would probably introduce more bureaucracy than most open source projects are willing to tolerate.

A much simpler solution would be to set up checksum servers separate from the ftp servers. These servers could use highly-restrictive firewalls that allow only the checksum-getting protocol through. I don't know what this protocol could be, but it wouldn't be impossible to set up a checksum daemon of some sort that did absolutely nothing other the delivering good checksums.

If these servers are administrated properly, it would only be possible for one--not both--of them to get cracked by the same exploits, thus greatly reducing the risk of trojaned software.

Re:How many people do check the MD5 checksum?

[Geekboy(Wizard)]

That is part of the port framework. You have a Makefile (which says where the file is, where to download it, what patches to install, what config options, what dependancies, etc, etc), a description of the port, any system specific patches (like OpenBSD only patches), and a file with an md5 checksum. The ports system will not "unzip" the file unless it matches the checksum. A simple "make REFETCH=true install" will keep downloading until a package that matches the md5sum is ready to be processed.

The only way that would fail, is if they trojaned your system, they trojaned the cvs tree and you updated against it (highly unlikely), or you used the NO_CHECKSUM=yes option, which IMHO is incredably stupid.

Re:How many people do check the MD5 checksum?

[Flower]

Here's my idea. Take it fwiw but it incorporates a concept Radia Perlman came up with. Create a number of CAs and have individual projects get a certificate from them. Use that to sign the MD5 sum which can go to a distributed repository. You grab the sum and verify it.

Once the cross connects for the CAs start to become unwieldy, create a higher level of CAs. The good thing about this is it isn't the anarchy model of trying to get everybody's GPG key and it is much easier to revoke a certificate unlike the current Verisign monopoly model.

I know this isn't the greatest description but does the idea make sense?

Re:How many people do check the MD5 checksum?

[msimm]

Can this step be automated? Say by Mozilla as an add-on or something?

I don't know anything about coding, but as a business manager I know the best way to get something done by the people you would like to do it is to make it so easy that its almost more work *not* to do it.

Generally people really appreciate well designed systems, I'd even say take pleasure in them..

Re:How many people do check the MD5 checksum?

[realdpk]

But in this case, the openssh tarball was trojaned at the openssh site. Wouldn't it seem reasonable that the FreeBSD port committer would have used that tarball, tested it (but not necessarily seen the trojan), then tar'd up the results and MD5'd them before uploading it to the FreeBSD site?

Maybe this wouldn't have happened here (since apparently the backdoor deleted itself), but it easily could have.

Re:How many people do check the MD5 checksum?

[realdpk]

Sounds good. Let's put Verisign in charge of it! ;)

But seriously, it does sound neat. An open-CA. You still have to trust that the committer themselves is not submitting bad code, or is not forged. (Even if the code is PGP/GPG signed, it could be forged, because the signing system could be compromised.)

Re:How many people do check the MD5 checksum?

[Anonymous Coward]

> I never check the MD5 checksum because I figure that if someone can crack the file they can replace the checksum. Having said that, I understand that the checksum and file may be in different locations, but often they are not. It would probably still make sense to check, though. An MD5 mismatch would be meaningful even if a match may not be.

Considering this exploit was caught by precisely this kind of checking, I'd say your post is correct, and that you'd better start.

Re:How many people do check the MD5 checksum?

[Rob Kaper]

Well considering the OpenSSH site still has not changed, nor the download, how can you be sure that someone didn't manage to alter DNS records or even the whois/SRS entries for the authorative name servers?

Re:How many people do check the MD5 checksum?

[kasperd]

I verified the gpg signature very carefully. After verifying I asked in a newsgroup just in case I would have missed something important. The public key I downloaded from a lot of different mirrors, just in case one of them had been compromised.

Re:How many people do check the MD5 checksum?

[peter]

No, silly, what we need is a GPG keyserver, so people can get keys from a separate source to check the sigs on files they download. We already have that, and it works fine. Some people just provide MD5 hashes, instead of actually signing their files, but that's something that may improve.

For an example of what I'm talking about, check out how www.kernel.org signs kernel tarballs and patches.

Re:How many people do check the MD5 checksum?

[prog-guru]

So the only way to get a matching md5 in ports for your trojaned openssh is to hack openssh's site and freebsd's site

wrong, they just need to hack freebsd's site, change the checksum, and change the location the ports system gets the tarball from, they can leave openssh's site alone.

and the ports system is designed to build software as root, one of the many reasons I avoid it.

Re:How many people do check the MD5 checksum?

[Tom]

There is no trusted 3rd party for this kind of problems. Relying on a single instance of trust will just mean that when the trust center gets hacked, we have a world-wide panic.

What we need is GPG (or other PKI) checking. md5 sums can be exchanged, too (and usually reside on the same server anyways), GPG signatures aren't subject to easy faking.

However, it's not quite that simple because you also need to distribute the public keys somehow, and in a trusted way. The problem is solveable, but non-trivial.

Re:How many people do check the MD5 checksum?

[repoleved]

and the ports system is designed to build software as root, one of the many reasons I avoid it.

So I am assuming you also avoid _installing_ as root, since otherwise you are still vulnerable to malicious install scripts.

Which makes me wonder... is there some logical way to install every piece of software with its own user name? Is that what the Solaris "wheel" group is about?

Hmm.. Let me take a shot at this. Add a user with the same name as the program. Add this user to the "programs" group.

chmod 7751 /usr/bin
chmod 7751 /usr/lib
chmod 7751 /usr/sbin

chgrp programs /usr/bin
chgrp programs /usr/lib
chgrp programs /usr/sbin

Install as the new user. Remove the shell for the new user. Right?

Re:How many people do check the MD5 checksum?

[prog-guru]

Well, you can just copy the binaries into place. And leaving the files owned by a user with no shell, or a user that doesn't exist would really have the same effect as leaving them owned by root, since the only one who can overwrite them is root. Yes, setuid/setgid is different.

Re:How many people do check the MD5 checksum?

[thomas.galvin]

What we need is a trusted 3rd party that has all the checksums.

Until that trusted third party gets rooted. What you really want is a bunch of third parties with checksums; much harder to infiltrate, much more secure.

Re:How many people do check the MD5 checksum?

[Ded Bob]

You are just begging for a fork in the back. :)

Re:How many people do check the MD5 checksum?

[repoleved]

Well, you can just copy the binaries into place. And leaving the files owned by a user with no shell, or a user that doesn't exist would really have the same effect as leaving them owned by root, since the only one who can overwrite them is root. Yes, setuid/setgid is different.

But how do you know what "make install" needs to do in any but the most simple Makefiles? Do you open the Makefile in vi with one window, and then manually copy the commands that make sense into another?

Plus, if you need to do the copying as root, then what stops you from inadvertently copying over a binary which already exists, thus altering the execution of other binaries by mistake?

Do you know of a systematic way to securely install programs without putting any other programs at risk?

Re:How many people do check the MD5 checksum?

[Tony-A]

That's assuming you can only have *one* place with all the checksums.
Better to have the checksums on different systems. Very different systems.

Re:How many people do check the MD5 checksum?

[Tony-A]

Right.
And it also answers the question of who's watching the watchers.

Checksum...?

[DJPenguin]

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

[Roofus]

OK so they trojaned the source tar.gz, and uploaded it to the server somehow. So why did they not update the MD5SUM also?

The checksums were already on the users FreeBSD machine.

Re:Checksum...?

[lertl]

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 :-)

Re:Checksum...?

[swdunlop]

They could have, if they had compromised an ftp site distributing FreeBSD, and modified the current ports package. That wouldn't have affected existing sites unless they updated their ports tree, which some bleeding-edge users are prone to do.

Re:Checksum...?

[crawling_chaos]

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.

This is another victory for Open Source!!!

[Anonymous Coward]

Isn't it?

Re:This is another victory for Open Source!!!

[Anonymous Coward]

Yes. It was found within 6 hours. Take any easter egg located in any microsoft project (excel flight sim), and you'll see it took them much longer to find. This is thanks to the fact that nobody trusts anybody else, and there are many checks and balances. OpenBSD guys distribute the openssh tar, freebsd guys generated checksums for their own system.

Re:This is another victory for Open Source!!!

[TandyMasterControl]

But I don't have to worry about it like the rest of you Linux using lusers cause I only use OpenBSD, the world's ONLY secure-by-default, completely auditted operati--
oh wait.

Idle curiosity

[Glytch]

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

[reeve]

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.

Re:Idle curiosity

[GCU Friendly Fire]

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.

I checked out this FAQ:
http://www.linuxsecurity.com/docs/harden-doc/html/ securing-debian-howto/ch7.en.html

In current Debian stable (Woody) there is a package called debsigs, containing the gpg signatures of the package maintainers, and another called debsig-verify, which when installed will cause all package installations to be conditional on checking against the keys in debsigs.

I ran an install on debsigs and debsig-verify in aptitude, but having installed debsig-verify _first_ apt refused to install debsigs on account of the fact that it could not verify the signature on the package. Silly, but kinda reassuring. Easily fixed by removing debsig-verify and explicitly reinstalling in debsigs _first_.

I hope they'll make debsigs a required main package in future, so that installation of debsig-verify will be completely painless.

Re:Idle curiosity

[GCU Friendly Fire]

Before anyone acts on my premature statements, there are some problems:

1. debsigs is not (as I assumed) the key list, which is in fact available from the Debian site as a tarball), but a tool for signing packages.
2. Debian Policy has not yet rolled out its package signing system, Debian packages are as yet unsigned, so there's little point in normal users installing debsig-verify.

This is not quite up to the standard I had come to expect from Debian.

My apologies go to anyone who was misled by my earlier statements.

Re:Idle curiosity

[Cupis]

1. debsigs is not (as I assumed) the key list, which is in fact available from the Debian site as a tarball), but a tool for signing packages.

I think you meant debian-keyring:

paul@kippax:~$ apt-cache show debian-keyring
Package: debian-keyring
Version: 2001.09.22
Priority: optional
Section: non-US
Maintainer: James Troup <keyring-maint@debian.org>
Recommends: gnupg (>= 1.0.3)
Architecture: all
Filename: dists/woody/non-US/main/binary-i386/debian-keyring _2001.09.22.deb
Size: 2271766
MD5sum: 4404d50f628ed2539d94d871a4def50c
Description: GnuPG (and obsolete PGP) keys of Debian Developers
The Debian project wants developers to digitally sign the announcements of their packages with GnuPG, to protect against forgeries. This package contains keyrings of GnuPG and (deprecated) PGP keys of developers.
installed-size: 2632

paul@kippax:~$

Trojan

[GigsVT]

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?

Re:Trojan

[Anonymous Coward]

IP Address 203.62.158.32 resolves to:
OEMCOMPUTER

HAHAHAHAHAHAHAHAHAHHAHAHAAHA

Result of the Reverse Lookup
IP address Result
203.62.158.32 snsonline.net [more info for this domain name]

Re:Trojan

[Anonymous Coward]

Tell me how this isn't a trojan again?

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:Trojan

[GigsVT]

Another reader writes, "Not really a trojan because all it does is make a connection to 203.62.158.32:6667."

This part of the story was what I was my comment was aimed at.

Re:Trojan

[JamesKPolk]

It's not a trojan on the output binary - it "merely" compromises the user account it is compiled on.

Bad? Yes. It could be worse, though.

Quality control and open source

[Anonymous Coward]

This is interesting. Open source developers are great, and we appreciate their contributions, but shouldn't there be some sort of open source code review? I understand that people that download the packages have the option to review the code, but I'm sure there's a lot that don't. Shouldn't some sort of change control/QC process be implemented before something is put up for the public's use?

Re:Quality control and open source

[Anonymous Coward]

Hush, you heretic! the next thing we know, you'll be asking for (gasp!) a _warranty_ !!

Re:Quality control and open source

[c13v3rm0nk3y]

The package _was_ quality checked prior to release. A previous post mentioned that the tarball was compromised on or about July 31.

That is, the compromised package was put in place long after this release had been officially released.

Re:Quality control and open source

[jasonrfink]

How does one QC a binary package everyday?
Besides, the comprimised server is sunOS 4.1, not openbsd brainiac.

It wasn't orgianally like that.

[Neon Spiral Injector]

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.

Re:It wasn't orgianally like that.

[Fluffy the Cat]

So if the file was modified it happen later.

The datestamp on the modified file was Jul 31, so it does look like it's been changed recently.

Re:It wasn't orgianally like that.

[Sibeling]

It's rumored to be only in Portable releases of openssh. Hence the p1 in 3.4p1. An interesting read is the thread it created on the FreeBSD list

Re:It wasn't orgianally like that.

[ahaning]

I downloaded and installed it yesterday, only to see this story today!

Nevertheless, my md5sum appears correct.

Unless the rogue code modifies the md5sum program(?).

Re:It wasn't orgianally like that.

[Anonymous Coward]

What, and binary-patches your kernel so that readdir() doesn't show you bf_test.c?

Re:It wasn't orgianally like that.

[Anonymous Coward]

The file on ftp.openbsd.org now has a date stamp
of june 26 01:20 837668 .
aug 01 2002, 10:50am EST

Re:It wasn't orgianally like that.

[Anonymous Coward]

You blubbering idiot. 'p' stands for 'patch-level'. Duh.

Re:It wasn't orgianally like that.

[Anonymous Coward]

Before calling people names, check your information out first...

http://www.openssh.org/portable.html

"The portable OpenSSH follows development of the official version, but releases are not synchronized. Portable releases are marked with a 'p' (e.g. 3.4p1). The official OpenBSD source will never use the 'p' suffix, but will instead increment the version number when they hit 'stable spots' in their development."

Another reason..

[prisen]

to subscribe to Bugtraq or a similar security mailing list. Especially you guys that run any type of server. Securityfocus is your friend; they'll have these advisories far in advance of any other place on the net.

Re:Another reason..

[SealBeater]

to subscribe to Bugtraq

It's funny cause I actually saw this appear on NANOG first.

SealBeater

Re:Another reason..

[Branc0]

And here is another good reason to unsubscribe from BugTraq and be part of another security mailing list.

Bugtraq is not the only one in the world you know?

what's up with OpenBSD?

[tps12]

I don't mean to be making a "*BSD is Dying" post, but what's the deal? This is the second problem with OpenSSH in a few months, and OpenSSL was exploited just a few days ago.

Is OpenBSD in trouble? More importantly, what are security-conscious people switching to, now that OpenBSD is no longer the fortress it once was?

Re:what's up with OpenBSD?

[JyB]

This has nothing to do with *BSD.

A package was trojaned on a SUNsite. Where's BSD in this ?

BTW, OpenSSL has nothing to do with *BSD. And the bug in OpenSSH was ... well ... shit happens, it's still humans who are coding ...

Re:what's up with OpenBSD?

[Anonymous Coward]

OpenSSL is a completely seperate project that OpenBSD (and just about every other vendor) happens to bundle.

Re:what's up with OpenBSD?

[Anonymous Coward]

Just because "Open" is in the name of "OpenSSL", you automaticly assume the OpenBSD people are the same people behind OpenSSL? That's not the case.

And why is OpenBSD in trouble? If you think OpenBSD is in trouble because of the bugs in Apache en OpenSSH, then I can assume you think RedHat is in a shitload of trouble (compare errata pages).

There are always bugs, and there always will be. Where software gets written, bugs are made. It's just that some OS developers (like the OpenBSD developers) tend to spend more time searching for those bugs than others.

Re:what's up with OpenBSD?

[Militant]

I am security conscious... and I am sticking with OpenBSD. It is still a strongly fortified OS. All of this software is secondary to the core OS.

OpenSSL is outside of OpenBSD, and has nothing to do with them. Everyone got affected the same.

They found the first remote exploit to affect OpenSSH in a long time (years) recently. Most people weren't affected. Ironically, it was OpenBSDs extra secure defaults that were vulnerable. Shit happens. The community was quick to patch their systems. Is Linux dying because it can be raped every week?

It appears the trojan was inserted after the initial release. So someone may have broken into the server. I believe the server is at the University of Calgary. Not Theo De Raadt's basement.

Why don't we wait to find out what happened? I guarantee this isn't being taken lightly.

Thanks

Re:what's up with OpenBSD?

[Mercaptan]

It's not in any trouble at all.

OpenBSD is less of a fortress and more of a flexible defense. In this case, even though the integrity of the centralized source code was compromised, any end-user who accessed it via the ports tree was immediately tipped off that something wasn't kosher. They could then communicate this to other users and the maintainers of OpenBSD and thus make this attack known to the public within hours of it happening. And due to the ease of updating that the ports tree provides, the maintainers of OpenBSD can correct this problem very quickly. This sort of suppleness provides for the best kind of broadband defense, whereas a "fortress" cannot brook much weakness in any of its parts and is far more brittle. Had users not been able to see the disparity (via MD5 sums), or not been able to communicate it to their fellow users, or not have been able to easily obtain a clean copy, then the problem may have been easily transmitted to a large number of operating OpenBSD machines. As it was, the problem got nipped at the bud.

This event would be the sort of reason why security-conscious people should stick with OpenBSD.

Re:what's up with OpenBSD?

[Anonymous Coward]

"fortress", haha.

You got sucked into the the openbsd marketing like every other linux user. Hah.

Re:what's up with OpenBSD?

[Anonymous Coward]

A package was trojaned on a SUNsite. Where's BSD in this ?

A package was trojaned on SUNsite, which happened to be ftp.openbsd.org Has every single last package on the same FTP server been checked? How many other packages have been trojaned? Have any other FTP servers been targetted?

This has everything to do with OpenBSD. They either have to practice what they preach, or shut up and go away. Trying to say it doesn't matter "because it was SUNsite and it was Solaris!" is bullshit; it was an OpenBSD domain, it was cracked, end of story.

Re:what's up with OpenBSD?

[duffbeer703]

OpenSSH is a subproject of the OpenBSD project.

The OpenBSD version (the refrence version) of SSH is unaffected by this trojan.

Re:what's up with OpenBSD?

[Anonymous Coward]

trojaned version of openssh on LINUX
not openbsd
openbsd is fine.
-
-
learn how to read people.

Re:what's up with OpenBSD?

[grub]

This is the second problem with OpenSSH in a few months, and OpenSSL was exploited just a few days ago

a) OpenSSL != OpenSSH
b) OpenBSD and OpenSSH both still have excellent track records compared to your average Linux[0] distribution.
c) If OpenSSH is really that much of a hole, write something better



[0] This is not a troll, it's reality. However being slashdot I'm sure to take a few karma hits for daring to speak like this..

Re:what's up with OpenBSD?

[timeOday]

In response to a), OpenSSH relies on OpenSSL. If OpenSSL is broken, so is OpenSSH. No fair for Nike to disclaim the quality of their shoes just because they choose to outsource them all to companies in third world countries.

In response to b), OpenSSH, apache, exim, and the kernel's firewall code are all that matter on my Linux box, because nothing else is accessible to the Internet. And of those four, OpenSSH/OpenSSL have been by far the most problematic lately.

In response to c), good point. And thankfully you don't see any rants about holding somebody "liable" for these mistakes, do you? The question is whether OpenSSH is technically sound, and there's nothing wrong with discussing that.

Re:what's up with OpenBSD?

[grub]

a) True enough, but the poster I was replying to was questioning if OpenBSD was in trouble because of the issues with OpenSSH and OpenSSL. If all the OSs that used OpenSSL were in trouble, we'd be wearing Borg implants. :)

b) If possible, it's not a bad idea to firewall SSH access to only those machines that require it[0]

c) Nothing at all wrong with discussing technical merits and shortcomings. Insinuating that OpenBSD is in trouble because of a few blemishes (as the original poster did) is silly IMHO.

[0] I'm a TinFoilHat OpenBSD user. A remote box I run only has SSH accessible through the VPN. IPSec'd SSH sounds like overkill, but I sleep very well. ;)

Re:what's up with OpenBSD?

[ImpTech]

I'm a big fan of OpenBSD and all, but point of order: ssh is NOT in the OpenBSD ports tree, which is why the vulnerability was discovered by a FreeBSD guy (its in their ports tree). I haven't heard how far this thing got into the OpenBSD system, for instance if it got into the patch branch. Maybe I'm missing something, but it seems to me that if it did get into the OpenBSD cvs tree, no amount of md5sums would help us.

Trojan executes code read via /bin/sh

[XTaran]

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?

Re:Trojan executes code read via /bin/sh

[Anonymous Coward]

Of course not. Real trojans would call /bin/bash.

Re: Trojan executes code read via /bin/sh

[XTaran]

Real trojans would call /bin/bash.

Think again. Trojans usually target towards portability, not to using programs with better user interface. With bash you wouldn't get access e.g. to most Solaris and SunOS systems.

Re: Trojan executes code read via /bin/sh

[Anonymous Coward]

So? It isn't just a badly designed trojan? It fits the description of a trojan with essentially everyone except the asshole BSD users.

Re: Trojan executes code read via /bin/sh

[Anonymous Coward]

>> Real trojans would call /bin/bash.
> Think again. Trojans usually target towards portability, not to using programs with better user interface. With bash you wouldn't get access e.g. to most Solaris and SunOS systems.

Please see your doctor ASAP; your humor transplant is being rejected.

Re: Trojan executes code read via /bin/sh

[XTaran]

No, it has been removed already.

SCNR.

Trojaned source distributions

[dzym]

So far we've seen dsniff and other programs from monkey.org trojaned, irssi, BitchX, 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.

Re:Trojaned source distributions

[Anonymous Coward]

Okay, publicly available security-related software
is and always has been vulnerable to hacking - no more (and probably less than) your average commercial product.
What is different about open source security software? It is uncontrollable - it is out there, replicated, digested and understood by many people.
So, take on the role of someone wanting you to stop using open source security software, what do you do?
You can't directly supress (ban) the products without showing your hand, so, as far as I know, the only thing you can do is undermine the respect for the product.
Slashdot readers will happily recognise moves by Microsoft to stiffle and control, but what would should you look for when talking about security software?
Who are the players? Who are the vested interests? How can the manifest their influence without showing their hand?

OpenSSL, OpenPGP et al *ARE* a thorn in the side of some organisation's agendas. If you think otherwise, you simply aren't thinking. So what do they do?
Undermine. Now, I'm not saying that THIS specific is a case of organised disinformation, but simply, well, HEADS UP!

Re:Trojaned source distributions

[dzym]

Erm, that reply was a bit more paranoid than I was hoping for.

Re:Trojaned source distributions

[mborland]

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

I agree...if you host code out on the internet, you should probably have a process on another machine that checks size/timestamps, or downloads the file and checks the signature of the file on the remote server on a routine basis. This way, if there is tampering, you know very soon thereafter.

Also, having checksums and signatures at sites separate from the downloads is a great idea (that helped identify the problem in this case).

Re:Trojaned source distributions

[Anonymous Coward]

I (being the same AC) am not trying to assert that this is part of some sort of plot. Only the following, weaker assertions:

- there are people and organisations who seek to exert control or at least monitor the population's discourse
- a free flow of information requires trust
- tools like SSH and PGP like protocols provide a means of free, unfettered and difficult to evesdrop exchange of information, and hence provide for a trust network
- now, IF you want to hi-jack this information exchange under the protocol, you are going to (a) want people to use it; and (b) break it (think Enigma *after* it was broken - thousands of people died as a consequence of hiding the fact that the Allies could listen)

And now:
- OpenSSH is demonstrably vulnerable to direct manipulation

So, of course, the question is: how do you make it harder for the attacker?

Bring on the signatures, checks and measures - again, HEADS UP. That is all I'm saying in this instance.

But as to why I'm saying it ... it gives me the shits when people say 'I have nothing to hide' or 'you're just being paranoid' - the point is no-one has a choice to opt out of the system - those doing to monitoring reserve the right to decide if you are of interest or not. Cryptography, at least with what is know to the general public, returns a certain amount of control back to the information producers and consumers, and I'd like to keep it that way.

Or in other words, take your paranoia quips and shove them - I guess I simply take this broader issue more seriously than some.

Regards,

AC.

Re:Trojaned source distributions

[ScottKin]

This post looks more like something I'd find in alt.conspiracy.

Can you say "paranoid"?

How to stop this happening again?

[uchian]

This is the one area with open source which I am suprised has not been exploited earlier, and it's a problem I'm not sure how can be avoided.

We see that the "many eyes" on open source seems to work pretty damn quickly : but the question is, how much damage could someone do in the time it takes for people to notice? Most software needs to be installed as root, and most people blindly install software without checking the make files to see what they do. Because it is run as root, you are leaving your machine wide open to anything the trojan wants to do.

yes | rm -r /

The trouble is, a normal virus checker wouldn't be any use against this kind of trojan as most damage is caused before the trojan is noticed.

Has anyone else thought about ways to solve this problem?

Re:How to stop this happening again?

[yatest5]

Has anyone else thought about ways to solve this problem?

Buy software produced by professionals?

Re:How to stop this happening again?

[Anonymous Coward]

It's MORE of a problem with closed-source. At least with open-source, you have some chance of discovering the trojan - the US government could be right now using undisclosed backdoors and trojans in closed-source packages for industrial espionage against western europe. They've done it before.

Re:How to stop this happening again?

[Anonymous Coward]

Buy software produced by professionals?

Yeah, and I suppose you say 'microsoft' is a professional?

Re:How to stop this happening again?

[ndecker]

Has anyone else thought about ways to solve this problem?

I think there are types of solutions:

• Technical: with ACLs and capabilities, it should be possible to restrict the damage that could be done by an installer. It might allow the installer to change the files belonging to the package and disallow any daemons running after the install and any network connections.

  These technical measures will provide some protection from simple attacks, but the attacker will know these measures too. There will be ways to bypass them.

• Social: Every package could be signed by some person. This signature could be checked on install. The problem is, that there are very few people trusted by everyone. These people probably couldn't check every update to every free package. If there are more, non-prominent "signers", it could be possible for some bad person to be considered trusted.

Re:How to stop this happening again?

[tburkhol]

Has anyone else thought about ways to solve this problem?

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 to stop this happening again?

[bockman]

I would add:

• Economic: This is a gooud reason, if you hare a business with money at risk, to use trusted source for your open source software, in change of a little of your money.

Re:How to stop this happening again?

[Anonymous Coward]

and I suppose h4x0rs are professionals too!
We call them security professionals

Re:How to stop this happening again?

[Hanashi]

I think a multi-pronged approach is in order.

First, open source project teams should try their best to make sure that their distribution points are secure. I know that no one intentionally distributes code from known-bad servers, but rather than just assuming security in the absence of knowledge to the contrary, I think they should make the security of their servers more of an active part of their project.

Second, they should register PGP keys with the key servers. Popular projects could even sign each other's keys, creating an informal web of trust. For example, the FreeBSD, OpenSSL and OpenSSH teams could maybe sign each others keys. This would help users make sure they don't download false keys from the servers.

Project teams should keep their private keys on read-only media (like a CD-R), and only 2 or 3 trusted members should be allowed to sign distributions. Really large projects could even do key splitting, so that (for example) 3 out of 5 developers are required in order to sign a release.

Of course, the project files should have detached signatures available in the same place that the distribution is. If it's FTP, put the detached signature in the same directory as the tarball. A lot of projects already do this. A pointer to the signature should be included in the project. Preferably, this should be in a standard file, like the $PROJECTROOT/SIGNATURE file, to make it easy to find.

If all these suggestions (or something like them) were followed, then someone who downloaded a package could use an automated tool to check the signature in one easy step. It is almost axiomatic that convenient security procedures get followed far more often than inconvenient ones, so I think automation is an important consideration here. It would add only one easy step, transmuting

configure && make && make install

to

checksig && configure && make && install

Re:How to stop this happening again?

[LinuxHam]

Because it is run as root, you are leaving your machine wide open to anything the trojan wants to do.

How about LIDS? LIDS lets you set r/w perms on files and directories and restrict actions that all users, even root, can perform. With a tight LIDS setup, root isn't even root. A simple example is setting /var/log/messages to read-only for everyone (that's users AND executables) except syslog and cron, and cron gets read-write perms only during the 1 minute a week it needs to rotate the log file.

That's pretty tight.

Re:How to stop this happening again?

[Anonymous Coward]

Hunt down and kill the people that do this shit.

OpenSSH

[Anonymous Coward]

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.

Re:OpenSSH

[Anonymous Coward]

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

Wait, what are you talking about? There is no malicious code for any operating system but Windows. I know, I read that here last week. You must be confused about the nature of the exploit. (And after Bill Gates made them spend a whole month fixing security holes! How weak.)

Re:OpenSSH

[Anonymous Coward]

So the way to minimize this class of problem is...

1. Actually check the MD5 sums.
(There are Windows programs that do this
if you need them. I did when I got
Mandrake 8.2 ISOs recently.)

2. Compile as a user OTHER than root.

2. a. Perhaps a quickly made up user, and
that account is deleted after compile?

3. If you have the skills (I admit I do not)
do some visual inspection of the source
looking for anything that seems out of place.

What I really wonder is how the trojan got there.
It is not reasonable for {a,the} OpenSSH maintainer(s) to have put it there.

Re:OpenSSH

[mce]

4: Compile on a system that is not connected to the net. Or at least properly firewalled.

Re:OpenSSH

[Anonymous Coward]

This means that vendors could be distributing unaffected binaries, but may themselves be compromised. Unless they have been diligent about md5 checksums, using chroot jails, and so on. No?

Yuck.

Re:OpenSSH

[orkysoft]

But that will only stop trojans that are active only during compilation, and not trojans inside binaries.

Re:OpenSSH

[mce]

Indeed. But this is a compilation tojan, after all. And it hurts most when one compiles as root on a machine that is connected. So...

I too am guilty of compilings things as root on my home box every now and then. Yeah, call me lazy, I know that I deserve it. But I do have a long standing rule that I never ever work as root, or even just log in as such, while connected (I have a dial-up line). Each program that is run by root is an additional security risk, even if it's run manually and only once every 6 months.

Re:OpenSSH

[Reziac]

Side effect: 203:62.158.32:6667 is presently quite thoroughly slashdotted.

Re:OpenSSH

[Anonymous Coward]

> 4: Compile on a system that is not connected to the net. Or at least properly firewalled.

What would be considered a proper firewall to protect against this outgoing-connection trojan?

Re:OpenSSH

[kasperd]

What would be considered a proper firewall to protect against this outgoing-connection trojan?

I use iptables, it is configured to REJECT all outgoing TCP connections except from destination ports of protocols that I regurarilly use. Had I run this trojan it would just have gotten connection refused, and the packet would have been logged to /var/log/messages.

Re:OpenSSH

[kasperd]

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

And don't expect the next one to be active only during build. It would have been trivial to make it more dangerous even for those people not using their root acount for compiling.

Re:OpenSSH

[samrolken]

If you use IRC, then this would have been one of those ports: 6667

Re:OpenSSH

[Fred Ferrigno]

The trojan could be easily modified to connect over port 80, and what firewall is going to block that?

Re:OpenSSH

[Bert64]

Considering the large number of freely available ssh trojans out there, it wouldn`t have been difficult to patch one of those into the code, thus affecting people who compile as nonroot, and those who install binaries compiled elsewhere. Also an extra process wouldn`t show up running on the machine.

looks like it's from our australian friends

[Anonymous Coward]

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

Re:looks like it's from our australian friends

[dzym]

That ip address means nothing. Having something so publicly visible in your artwork would be like signing the graffiti you just sprayed all over the base of the statue of liberty with your real name and leaving a phone number.

It's definitely going to be just another 0wn3d box like with the BitchX source ./configure trojan.

Re:looks like it's from our australian friends

[GigsVT]

It's funny that the hacked box was originally running Red Hat Linux, then switched to FreeBSD according to netcraft. Guess they should have stuck with the more secure system.

Re:looks like it's from our australian friends

[Anonymous Coward]

You might be right about it being owned. However is that one at that location that needs to be looked at. The cracker may or may not have left evidence of other break-ins or trojan programs

Re:looks like it's from our australian friends

[Anonymous Coward]

Or maybe someone who didn't like them? Dumbass.

Re:looks like it's from our australian friends

[Anonymous Coward]

That's not the point. We/they chould have checked out the computer to see what else is on it. But it looks like the machine was rebuild. :-(

Re:looks like it's from our australian friends

[jquirke]

FreeBSD != OpenBSD

--jquirke

Re:looks like it's from our australian friends

[jquirke]

Yeah right, like they are going to sign their name on a Trojan. No one could be that stupid.

However, what you have just done is published the address of the 'victim', which is possibly what the original author of the trojan wanted.

Now Melbourne slashdotters who think like you will be paying a visit to this address, the next time I'm walking along Bourke I'll look out for any damage they may have caused.

--jquirke

Re:looks like it's from our australian friends

[jquirke]

Sorry, it's late and I'm not thinking straight.

Mod my post down please.

Re:looks like it's from our australian friends

[Anonymous Coward]

You do know that this is publicly avaible information? Second I'm not saying that they did it just that its sending to a computer in australia. That now we find out it was rebuild sone after the trojan, so now it isn't possible to check who did hack that computer.

BTW: is some kind of delay here? my posts almost always get posted within 20 sec. Where as some of the other posts on this thread look like the they didn't see the previous posts ??

Re:looks like it's from our australian friends

[Anonymous Coward]

Damm earthlings. We'll make them pay, Kronos.

Re:looks like it's from our australian friends

[Anonymous Coward]

Uhh.. a better observation would have been.. they should have stuck with a system that they could actually administer. Point your finger to the admin, not the OS, I cant believe this actually needed to be said.

Re:looks like it's from our australian friends

[ViVeLaMe]

URL?
here's what netcraft has to say:

(blahblahblah, yeah, apache/FreeBSD)

FreeBSD users include www.aldigital.co.uk, Orange, www.yahoo.com and The Apache Project

We have no uptime data for 203.62.158.32 at present, and cannot plot a graph.

The host 203.62.158.32 has been added to the list of sites that we may monitor. We will start monitoring 203.62.158.32 in the next daily monitoring cycle.

We will continue to monitor this host for a few days, to get enough values to plot a graph. After this time the host will not be monitored again unless it's requested again, or it is one of the most frequently requested hosts.

So it wasn't monitored.
Lame Troll Spotted.

Re:looks like it's from our australian friends

[GigsVT]

What? Read the OS history, it was hosted on Red Hat, then switched to BSD.

FreeBSD
Apache/1.3.26 (Unix) mod_jk/1.1.0 mod_perl/1.27 mod_ssl/2.8.10 OpenSSL/0.9.6a PHP/4.2.2 mod_fastcgi/2.2.12 mod_python/2.7.8 Python/ 2.2.1
1-Aug- 2002
203.62.158.32
Australian TeleServices Pty Ltd
FreeBSD
Apache/1.3.24 (Unix) mod_jk mod_ssl/2.8.8 OpenSSL/0.9.6a PHP/4.1.2 PHP/3.0.17 mod_fastcgi/2.2.12 mod_python/2.7.6 Python/2.2 mod_perl/1.26
11-Apr- 2002
203.62.158.32
Australian TeleServices Pty Ltd
Linux
Apache/1.3.12 (Unix) (Red Hat/Linux) PHP/3.0.15 mod_perl/1.21
1-Jan- 2001
210.9.53.32
connect.com.au Pty Ltd

It was just a joke anyway. I guess any joke about BSD is automatically a troll now?

Re: Ummm... actually it has

[Anonymous Coward]

Actually this has happened to numerous microsoft apps. Not the least of which is Windows XP, which allows M$ to backdoor you whenever they please.

RTFM man, and stop being such a microsoft junkie. Microsoft has it's place but doesn't deserve a pedistal. Flat out, it sucks.

What's the big worry

[back@slash]

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.

Re:What's the big worry

[Anonymous Coward]

My shell said "Bad Command or File Name."

Re:What's the big worry

[kludge99]

either does that C:\> prompt

Re:Oh my!!!

[Anonymous Coward]

Me thinks Bill gave a good part of his working force some time off today, so that they could stroll over to /. and unload their hatred upon a unsuspecting crowd of bewildered /.'ers who believed that OpenBsd could never be hacked. Shit happens, SNAFU. At least I(as a linux-user)don't have to agree to an EULA that *gives* legal rights to Micro$hit to have full control over my box. But hey, rant all you want, it's not every day *this* happens!

BTW, and if I did not mentioned it, the OS of BSOD's is so full of bugs and shit, my head spins just thinking about it; and I try every day to forget the days of horror when it was my profession to work with this piece of crap. General Protection Error, my ass!

Healthy versions still available..?

[virve]

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

Re:Healthy versions still available..?

[Anonymous Coward]

The copy on Wiretapped.net is also clean.

This mirror will not be updated from ftp.openbsd.org until it is cleared by the OpenBSD team.

ftp://ftp.wiretapped.net/pub/OpenBSD/OpenSSH/porta ble/openssh-3.4p1.tar.gz

Re:Healthy versions still available..?

[Anonymous Coward]

file has been updated on ftp.openbsd.org
the system works.
its not perfect but the system works.

Dit it make into any distro?

[bockman]

Do distro check package checksum, before distributing package upgrades?

I think that after that, they are going to ask digital signature by any of the upstream mantainers.

So, this may turn in a good thing ... if it didn't make too much damage.

Oh, and just for karma: this shows once more that security is a process more than a product.

My analysis

[lertl]

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 www.openbsd.org (and ftp.openbsd.org) is run on Solaris.

Re:My analysis

[Anonymous Coward]

Not Solaris, SunOS 4.1

Re:My analysis

[Anonymous Coward]

Not Solaris, SunOS 4.1

a.k.a. Solaris 1.0?

Re:My analysis

[Anonymous Coward]

ftp.openbsd.org and www.openbsd.org are run on SunOS 4, not Solaris. I'm going to avoid the Solaris 1 vs. Solaris 2 debate here.

Kris

Slashdotted (copy of the weblog)

[MavEtJu]

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.

Re:Slashdotted (copy of the weblog)

[smnolde]

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.

Re:Slashdotted (copy of the weblog)

[Proquar]

Mavvie, You rule!

(Btw "Mavvie" = "the guy who found the trojan")

Re:Slashdotted (copy of the weblog)

[Anonymous Coward]

Hmmm about Mavvie,

If you streach it a bit and using Occam's Raznor, I wouldn't be suprised if this guy was the person behind it and did this as an attmept to try to gain some favor among the community. Didn't he even speak to the rint person up front, and write this sorta advisory?

I think this warrents some checking into. I woulnd't trust this guy as I would trust the next dude.

Re:Slashdotted (copy of the weblog)

[Proquar]

I don't think people should be able to post as anonymous gutless cowards!

You go right ahead - and check into Mavvie - and then you - you gutless, stupid wonder playing at Columbo - can apologise!

The guy saves the world - and you can't even accuse him with an identity.

Mavvie rules! Anonymous cowards usually suck - and this one's the pits.

Re:Slashdotted (copy of the weblog)

[tallackn]

You go girl!!!

Re:Slashdotted (copy of the weblog)

[Anonymous Coward]

Building with user privileges certainly wouldn't make me feel safe from trojans, since most trojans would affect the installed binary rather than the build...and thus anyone who runs the binary.

If I were going to create a trojan, I'd put it in a daemon that has to run as root.

The MD5 sums are a pretty good safeguard, unless of course the trojan went unnoticed by the port maintainer. Or the ports tree itself was compromised.

Ensuring that ports are safe (in addition to being nearly impossible) would reduce the number of ports available.

Security and functionality are often mutually exclusive.

Re:Slashdotted (copy of the weblog)

[Eggplant62]

You may want to tell ^Sarge^ that he should secure the open http proxy running on port 8080. I'm certain that his machine is undoubtedly routing plenty of spam for various and sundry assholes around the 'net.

*Tsk*

Rich

Gentoo...

[Bush_man10]

I wonder what what would happen if someone was installing Gentoo? :) Shitty deal if you ask me

Re:Gentoo...

[ndecker]

I read it first on gentoo-dev. The ebuild is not affected. The checksum in the ebuild will fail against the compromised tarball.

Re:Gentoo...

[Anonymous Coward]

Nothing whatsoever. The openssh ebuild would fail before it even untarred the source code because the md5sum would not match... Now, if someone were foolish enough to make an ebuild w/ the checksum of a trojanned package, we'd all be out of luck. In this case, and in the case of any but the most sofisticated man-in-the-middle attacks, though, Gentoo is quite safe.

Re:Gentoo...

[Spider[DAC]]

Actually not.
Gentoo does md5 checksumming as well, and unless you specifically override it (about the same way of *BSD) it will bail out and complain that the md5 sum mismatch.

besides, Gentoo also uses a set of Mirrors, and the files on the mirrors were ualtered.

Well, I guess that's what they get...

[MrBadbar]

...for hosting ftp.openbsd.org on a box running SunOS, not OpenBSD!

Re:Well, I guess that's what they get...

[pmz]

Well, I guess that's what they get for hosting ftp.openbsd.org on a box running SunOS, not OpenBSD!

Not quite. Solaris really can be secured almost as well as OpenBSD. It just takes more effort, and the administrators of the FTP server probably didn't bother.

Re:Well, I guess that's what they get...

[dohcvtec]

When you login to the FTP site, it says SunOS 4.1. This is SunOS, not Solaris. IIRC any version of Solaris is identified as SunOS 5.x. So the question is, how secure is this antique OS?

Re:Well, I guess that's what they get...

[pmz]

When you login to the FTP site, it says SunOS 4.1. This is SunOS, not Solaris. IIRC any version of Solaris is identified as SunOS 5.x. So the question is, how secure is this antique OS?

SunOS 4.X was rebranded "Solaris 1.X" some time ago, to make it seem more in-line with the SunOS 5.X development. I suppose any UNIX, regardless of age, can be fairly well secured. It just takes a lot of knowledge and intuition about network services, file permissions, etc.

Re:Well, I guess that's what they get...

[strombrg]

Hm. It's apparently SunOS 4.1.x, for Pete's sake. Someone's a glutton for punishment.

i'm more interested to know *who* did it

[Anonymous Coward]

Is it just some disgruntled programmer? Was it the BSD team itself doing a drill check of their own security? Or is it time for conspiracy theories -- the men in black, or blue perhaps? (well, I dunno what colour Microsoft is, but they're the new IBM so I chose blue..)

New catch phrase

[martinde]

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

[LizardKing]

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.

Re:New catch phrase

[windex]

You are wrong. Why don't you read the fucking article. Mabye you could quit being some kind of egotistical openbsd-zelot as well?

Re:New catch phrase

[dohcvtec]

How can speaking the truth be termed "being some kind of egotistical openbsd-zelot?" The compromised tarball is for OpenSSH Portable you nitwit. The OpenSSH binaries for OpenBSD 3.1 are in the distribution *.tgz files. These are not compromised, therefore, the claim on www.openbsd.org stands. Furthermore, the source code tarball of the OpenBSD version of OpenSSH was not compromised either. These tarballs are used to upgrade OpenSSH on an OpenBSD system, so they have nothing to do with a deafult install. However, since it is the portable version that was compromised, other OSs that use said tarball may have "a remote hole in the default install."

Re:New catch phrase

[Anonymous Coward]

The normal (OpenBSD) version was also trojaned. RTFA.

Re:New catch phrase

[Anonymous Coward]

The openBSD version of openssh was not trojaned.
rtfa yourself.

Re:New catch phrase

[Anonymous Coward]

Bzzt...

Non-portable was trojaned too.

Re:New catch phrase

[dohcvtec]

Do you understand English? You and the OP are going around in circles. Neither the binary or source native OpenBSD versions of OpenSSH were trojaned. This is consistent with the article, and I just checked the actual source tarball myself. Oh, and by the way, this has nothing to do with the default install :)

Re:New catch phrase

[iabervon]

One remote hole in the default install, and one in the default update?

I think their catchphrase only actually applies to their code, not their distribution site; the version with the trojan isn't really their software.

Re:New catch phrase

[Anonymous Coward]

actually i do not understand english so well.
me being swedish and all.
Oh. You aren't talking to me?
never mind.

Re:New catch phrase

[Anonymous Coward]

Can you read?

What part of "The portable version wasn't the only which was trojaned, the normal version was also." don't you understand?

The FTP archives were probably fixed as soon as the problem was discovered. Do you think they'd leave the trojaned versions in place for everyone to download?

Re:New catch phrase

[mat.h]

Sorry, this is so stupid it's not "Score 5, funny". AFAICT neither the OpenBSD 3.1 distribution nor the CVS repository are affected. This is strictly for people who are 'leet enough to build everything themselves, think that packaging or ports systems are for sissies, and at the same time dumb enough not to check signatures or MD5s from a trusted or at least different source.

Re:New catch phrase

[bockman]

Anyway, the port system of *BSD refuses to compile the trojaned source package because it checks the MD5 (which comes from non-compromised source).

So the problem is for non-bsd users of OpenSSH, which downloaded and installed the source without bothering to check the MD5 (or having their system to check it for them).

Re:New catch phrase

[Anonymous Coward]

I'm sorry, it's just your use of BOLD, HEY, I KNOW, YOUR STUPID letters that made me respond. I really do actually love you.

It was worth loosing 1 chunk of karma for the effect. :D

Re:New catch phrase

[Syberghost]

Not counting the other remote holes in the default install from the last few months.

But, hey, Theo ain't counting 'em either.

The real issue is persistence

[f00zbll]

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.

Re:The real issue is persistence

[JimPooley]

On my free time, I do read through open source code for fun.
You really need to get out more...

Just a Thought to prevent this..

[Akor]

If there would be some configure/make environment that prevents or asks before outgoing connections and checks for possibly dangerous commands, that are unusual to call upon a ./configure run, wouldn't that prevent things like this to happen again?

Re:Just a Thought to prevent this..

[yatest5]

If there would be some configure/make environment that prevents or asks before outgoing connections and checks for possibly dangerous commands, that are unusual to call upon a ./configure run, wouldn't that prevent things like this to happen again?


Yes, I recommend having the installation banned from creating / deleting / running any files.

Re:Just a Thought to prevent this..

[Grax]

I would like to see a wrapper or shell or something that prevents internet connections from its children and logs any attempts.

This would be great for a build environment and for other executables that don't need network access.

Re:Just a Thought to prevent this..

[Akor]

I wrote commands, that are _unusual to call_

btw, I don't see why the configure/make process (not make clean or anything) needs to delete/run anything besides the compiler.
I mean, maybe there could be a restricted shell for compiling, that can't really do anything bad to the system. And yes, it's an unfinished, maybe naive thought =)

Re:Just a Thought to prevent this..

[Skapare]

In FreeBSD, I think jail can do this. In Linux there is an add-on called vserver that can do this (assign a private address to the context where you do the builds). Of course it can write all over the files in the chrooted directory, and that can compromize the resultant binary.

Re:Just a Thought to prevent this..

[yatest5]

Sorry man, it was an easy +5 karma target, and I need it to wind up people on here :)

Warning...

[Anonymous Coward]

Updating SSL and/or SSH may fsck you up, if you are doing it remotely via said ssh shell. :-(

Heh...

[Anonymous Coward]

With the monthly (if not more often) security problems with that package its the reason why I stick with this instead.

I just don't have the time to constantly update my home systems like this.

Re:Heh...

[Anonymous Coward]

And how do you know the mirror sites that ssh.fi direct you to from their download page are secure?

It's a rhetorical question, of course.

slashdot is missing a great opportunity to help

[back@slash]

The right thing to do here would be to put a link in the article to port 80 of the receiver server of the trojan.

Let's see it try to work while the server is being /.'d into oblivion.

Re:j00 R 0wn3d lol

[Anonymous Coward]

No, Microsoft just distribute viruses along with their updates.

Although I do agree that it is now time for the OpenBSD users to shut the fuck up, pack up, and go home. On the way out they can hand the OpenSSH code over to some competent developers who don't have an attitude problem.

Re:j00 R 0wn3d lol

[Anonymous Coward]

Ever heard of the "security patch" for XP and Media Player? Right in the EULA you give Micro$loth admin rights to your machine - hell, they put it in clear english! I'm sorry, but a media player should not be able to root the box, period. And the "fix" itself could be considered a trojan - one with a legal EULA to boot!

So you must not run XP, right? I know a guy who firewalls his XP box, not so much to keep others out, but to keep data in! He uses egress filters to stop unauthorized outgoing traffic. And, yes, XP tries to report back to Redmond.

This rogue code was caught within 6 hours. It would take at least 6 days for M$ to even admit that the trojan existed (that is, if they would admit to it at all). Micro$loths security record is hardly something to brag about. On the other hand, OpenBSD's record up til recently has been very impressive, to say the least.

Why aren't people asking as to whom is doing this?

[Anonymous Coward]

Could it be that a certain software corporation is hiring PR firms to do this?

I seem to remember a certain software corporating having the hotel room of some IBM execuatives bugged (does anyone remember this?).

FUD

[Anonymous Coward]

1. This does not affect the installation.

2. This is not an OpenBSD matter.

Re:FUD

[Anonymous Coward]

The normal (OpenBSD) version was also trojaned. RTFA.

Re:FUD

[Anonymous Coward]

The "normal" OpenBSD version comes with the system in the default install, not in a tar ball.

Re:FUD

[Anonymous Coward]

RTFA yourself, sexless fuckwit.

"The tarball of the portable OpenSSH on ftp.openbsd.org is trojaned. The backdoor is only used during build - generated binaries are fine."

see 'portable' ?

openssh in the installation comes from the distributed .tgzs.

Re:FUD

[Anonymous Coward]

Can you read?

What part of "The portable version wasn't the only which was trojaned, the normal version was also." don't you understand?

The FTP archives were probably fixed as soon as the problem was discovered. Do you think they'd leave the trojaned versions in place for everyone to download?

BTW, the bug that posts replies twice is pretty cool! :^P

How was that possible

[ndecker]

I think it is important to know, how the compromised tarball got to ftp.openbsd.org. If that box was compromised the attacker could have changed the checksums too.

Without those checksums, the trojan might have done much more damage.

Re:How was that possible

[Anonymous Coward]

It was compromised, but the revealing checksums were from the FreeBSD ports-tree, not the checksum file on the ftp site.

Checksums in the same place as the distribution generally only protect against accidental corruption.

Why not hack the md5 checksums?

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

Re:Why not hack the md5 checksums?

[disappear]

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.

Re:Why not hack the md5 checksums?

[slamb]

This is a solved problem. Red Hat, for example, GPG signs the MD5SUM file.

That's a solved problem for RedHat (and other large distributors). You still need a secure channel to get their GPG public key. In RedHat's case, they can ship it on the CD in anticipation of updates. For small people, they need to offer it on their website (same problem) or use our existing (imperfect) PKI system.

Re:Why not hack the md5 checksums?

[glwtta]

some linuxes (*cough* Gentoo *cough*) have systems similar to BSD ports which would catch it. the good news is that it takes one person (running one of these systems) noticing it to bring the trojan to light and correct it; what was it in this case, 6 hours? I don't think I'm gonna panic just yet

Open Source PKI Needed?

[carbon60]

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

Re:Open Source PKI Needed?

[Anonymous Coward]

apt-get from debian does no checking at all. The RPM version of apt, though, has digital signature check builtin.

Re:Open Source PKI Needed?

[carbon60]

This would be a Bad Thing. Anyone know of plans to do something?

Re:Open Source PKI Needed?

[Anonymous Coward]

"Debian takes security very seriously", apparently.
So, there are obviously (in a purely sarcastic sense of the word), measures prevent DNS spoofing of security.debian.org.

Well?

Re:Open Source PKI Needed?

[hyperstation]

you could dump debian and use gentoo

Re:Open Source PKI Needed?

[fizbin]

Except that then you would be bitten by stuff like this that trojans the makefiles.

As far as trojaning individual .deb packages, apt-get will indeed abort if the download md5sum doesn't match the md5 recorded in the Packages file. However, there is damn near nothing to verify that the Packages file is what it ought to be. (And since .debs and Package files are pulled from the same place...)

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.

Re:Open Source PKI Needed?

[groen]

you could dump debian and use gentoo

Actually, I was worried already about the way gentoo might be heading. See this proposal which seems to make a lot of people enthusiastic. It talks about a system where "everyone" can contribute with packages/ebuilds and there is a voting system that determines whether this package is tagged new, or approved or whatever. There is a thread on the Debian mailing list about it starting here.

Richard

Re:Open Source PKI Needed?

[Anonymous Coward]

That's just typical debian fud.

Debian has been spreading myths, half-truths and lies about redhat for years.

Now that gentoo is get popular and winning converts from debian they will start the FUD attacks on debian.

I have used debian for years, but i got sick of excuses and FUD so i went elsewhere. Debian has many gaping huge problems but if you try and address them you are hit with a wall of excuses or FUD. The debian project is just getting inbred, there's no one left to say the emperor has no clothes any more.

Re:Open Source PKI Needed?

[hyperstation]

precisely. and i get modded to flamebait. did i say anything *bad* about debian? no. so now even recommending another distro over it is cause for concern, i guess...

Re:Open Source PKI Needed?

[Anonymous Coward]

Welcome to Slashdot...

Re:Open Source PKI Needed?

[cras]

What if every package maintainer signed the packages with his own signature, and that was added into Packages file? Then some .deb which contains everyone's signatures and dpkg would verify them. This would sound pretty good to me at least.

Re:Open Source PKI Needed?

[Anonymous Coward]

> Actually, I was worried already about the way gentoo might be heading. See this proposal [gentoo.org] which seems to make a lot of people enthusiastic. It talks about a system where "everyone" can contribute with packages/ebuilds and there is a voting system that determines whether this package is tagged new, or approved or whatever. There is a thread on the Debian mailing list about it starting here [debian.org].

And from reading that thread, it seems the idea went over like a led zeppelin.

Re:Open Source PKI Needed?

[fizbin]

Well, there is already a .deb that contains every developer's public key, and in fact developers do send a gpg-signed message to the debian-devel-changes list when an upload is made, so some of the pieces are there.

As I said before though, the glue to hold all this together keeps getting bogged down by the stuff it won't fix.

Re:Open Source PKI Needed?

[Anonymous Coward]

This is what I don't get when people argue back and forth about .deb versus .rpm. For the most part, the packages do the same things. But here's something that ought to be a showstopper, that RPM does and that .deb doesn't do.

RPM has had support for cryptographic signatures for years. The public key infrastructure has been in place for years. The internet has been an unsafe place for years. Why do people still insist on using .deb in the face of this? Why do people not insist on signed source? It's important, and it's not that hard to do.

Surely you jest!

[Anonymous Coward]

Personality factors? With the OpenBSD coding team? Those guys are the nicest, most patient, most tolerant group of techies you'll ever meet!

GnuPG a good idea

[giminy]

Once again I call people's attention to GPG, which can be used to digitally sign source code. Then, if something is trojaned, you know who to blame for including the bum code.

Re:GnuPG a good idea

[Gemini]

It's worth pointing out here that the code was signed, and the signature worked - it shows the tarball as modified.

The catch is that not enough people actually checked the signature.

Re:GnuPG a good idea

[Abcd1234]

Actually, the code wasn't "signed" in the cryptographic sense. The code was checksummed, and that checksum showed there was a problem. However, there is nothing stopping someone from modifying the checksum and making the archive appear legit.

Real cryptographic signing, like that mentioned in the grandparent post, involves hashing the tarball using a strong hash, and then encrypting that hash using the private key of the signer. Then, any person can retrieve the public key of the signer and verify that the "signature" is legitimate by attempting to decrypt the hash (this is probably not strictly correct with the way things really work, but the concept is, AFAIK, correct). The point is that the only person who can "sign" the tarball is limited to only legitimate people (or organizations). So, if the signature for the tarball is valid, you can guarantee it was signed by someone you trust, and so you can trust the code.

Re:GnuPG a good idea

[OttoM]

The info on the difference between a secure hash and a signature may be correct, but if you look in the archive, you'll find out that the code is signed:

ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portab le /openssh-3.4p1.tar.gz.sig

This file contains a GnuPG sig, and the trojaned tarball fails verification.

Re:Why aren't people asking as to whom is doing th

[dfn5]

I was wondering the same thing. How did the file get uploaded to the ftp server? Who did it? And can they be prosecuted?

DON'T DO THAT !!!

[Salsaman]

The IP address is of the machine which was hosting the ssh tarball. The attacker was obviously hoping to 0wn the machine and then pick up all the incoming connections.

Re:DON'T DO THAT !!!

[back@slash]

It was just a joke, try not to freak out too much.

Besides according to this (very suspicious) post the machine has already been rebuilt anyways.

hostinfo

[suwain_2]

$ 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?

Re:hostinfo

[mindriot]

The box is already secured according to this post. If you read the weblog by the guy who found the exploit (mirrored here), you will see that he (by some luck) got in touch with ^Sarge^, the owner of the box.

Before patching...

[Anonymous Coward]

For all the users who are confused, but are running OpenBSD pf or FreeBSD with ipfw, you could simply block all outgoing TCP and UDP packets to that address so the trojan simply won't communicate with the home server. Remember, a good hacker could simply use arp-poisoning or an arp spoofer to pretend to be that server. If you block it, you can still run OpenSSH with the trojan, and it's secure.

Portscan of the backdoor IP

[CajunArson]

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.

Not the fault of OpenBSD?

[Anonymous Coward]

Are you saying it's not the fault of the OpenBSD OS or the OpenBSD team?

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:Not the fault of OpenBSD?

[lertl]

I just wanted to prevent the upcoming "OpenBSD? Har har har, secure as Cheddar Cheese or what?" flamewars.

Re:Not the fault of OpenBSD?

[Tuzanor]

Actually, they aren't the ones running the box. openbsd.org and openssh.org (including the main ftp servers) are run on Solaris at the University of Alberta in Calgary. This is because the Universtity has offered free bandwidth, and for projects as large as openbsd/openssh, free bandwidth is a godsend.

Re:Not the fault of OpenBSD?

[Anonymous Coward]

These guys do good work, but don't discredit the possibility that they make mistakes themselves once in awhile.

... and, since they do such good work, they develop a overdeveloped sense of invulnerability

Re:Not the fault of OpenBSD?

[dadragon]

Actually, they aren't the ones running the box. openbsd.org and openssh.org (including the main ftp servers) are run on Solaris at the University of Alberta in Calgary.

Actually, the University of Alberta is in Edmonton. The one in Clagary is the University of Calgary :) You're probably thinking of Theo, who is in Calgary.

This is because the Universtity has offered free bandwidth, and for projects as large as openbsd/openssh, free bandwidth is a godsend.

sunsite.ualberta.ca is very fast, with a fat pipe to the outside world (or at least to the rest of Canada). If I was offered webspace or ftp space on it, I wouldn't turn it down :)

Re:Not the fault of OpenBSD?

[Anonymous Coward]

Just a note, as student of the University of Alberta, it is actually in Edmonton...not Calgary.

000 days since last trojan

[Anonymous Coward]

Ummm, not quite.

[jotaeleemeese]

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

Prescient Alan Cox / Theo exchange

[wfrp01]

Check out this little snippet (the whole message 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

Re:Prescient Alan Cox / Theo exchange

[wfrp01]

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

Re:Prescient Alan Cox / Theo exchange

[wfrp01]

FWIW, I agree with the comment made by The_Noid on the same lwn page I previously mentioned about how the manner in which Theo handled this was very appropriate:

If the details to this vulnerability would have been released (even with patches) just about every Linux box on the planet would have been cracked before the owners would've had time to install the patch. Publishing a fix to this problem will only tell the cracker exactly where the problem is.

So they first work around the bug, without actually fixing the bug and telling what is it and where it is, so crackers can't make an exploit before people are immune (and I repeat, a direct fix would exactly tell the cracker what the bug is.)

A bug like this is what every cracker is dreaming of, a way into just about every unix machine on the planet!

This whole episode is very bizarre.

Re:Prescient Alan Cox / Theo exchange

[Florian Weimer]

If the details to this vulnerability would have been released (even with patches) just about every Linux box on the planet would have been cracked before the owners would've had time to install the patch. Publishing a fix to this problem will only tell the cracker exactly where the problem is.

Nice story, but most GNU/Linux systems weren't affected by this bug at all. Unfortunately, we now know that privilege separation didn't help much because of BSD kernel bug.

Re:Prescient Alan Cox / Theo exchange

[wfrp01]

Oh, I agree with you. I'm just saying this sounds like a reasonable explanation of how to respond to an exploit of this nature.

suspicious! person who reported KNEW ip owner

[Anonymous Coward]

If you look at the reporting site, the person who reported it alleges that he went into an IRC channel, and immediately ended up speaking to the very owner of the machine which the trojan connects to.

Now, what are the chances of that happening? Finding a random trojan on your machine, popping in to an IRC channel, and immediately walking in on the owner of the machine from which the backdoor seems to originate? Who then immediately states "ah yes, that's my machine!" and closes the offending port. Well, how many machines are there on the 'net -- you work it out.

Sorry, my friends, but this smells of bullshit to me. I think the guy who reported it knows a lot more about it than he's making on... if he didn't write and install the bf-test himself, I would hazard a guess he knows who did. And, as the guy who reported the issue, he is least likely to be suspected... which makes the whole thing all the more cunning, if my suspicions are correct.

Re:suspicious! person who reported KNEW ip owner

[palfreman]

Maybe it a conspiracy, but there is a small but perfectly viable chance that the person discovering an exploit would be on an IRC channel at the same time as the person whos box had been owned. Statistically it is bound to happen every now and again.

Re:suspicious! person who reported KNEW ip owner

[Anonymous Coward]

Why is the above flamebait? Did anyone actually read and consider it?

OT: if you're going to quote, then QUOTE

[Anonymous Coward]

• This is a local shop for local people! Don't touch the pretty things!

The only thing lower than quoting someone else's words in your sig is misquoting them. It's the precious things

for more information

[shivan]

check out this bugtraq posting for a small analysis of the trojan.

DUH!

[4of12]

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.

Re:DUH!

[Tony-A]

Like, if I were a Trojan cracker I would make sure to make the md5sum on the web page match the new tar ball. Problem is all those lazy bastards who download the web page one day, the tarball another day, and cross-reference the cache of some other lazy bastard, and get inquisitive about anything that moves.
You can fool some of the people all of the time. You can fool all of the people some of the time. It's very hard to fool all of the people all of the time. It's the lazy bastards who notice something not quite right that cross you up.

Telnet - because Theo is an asshole

[Anonymous Coward]

Telnet - because Theo is an asshole

Re:Telnet - because Theo is an asshole

[Anonymous Coward]

telnet - because all good american PATRIOTS should!

(read: The NSA looooves your plaintext)

Re:Telnet - because Theo is an asshole

[Anonymous Coward]

The NSA is going to know that my wife asked me to pick up milk on my way home from work? FUCK!!

Re:Telnet - because Theo is an asshole

[arkane1234]

and that your password on a server is m@st3rb@t10n.
Hell, screw the NSA... any script kiddie could find that out through telnet.

Besides, when was the last time your wife typed for you to pick up a bottle of milk on your way home through telnet?

Re:Telnet - because Theo is an asshole

[Anonymous Coward]

Are you unclear on the concept of reading your mail somewhere besides the mail client at your desk? It's really not that tough to figure out...

Re:Telnet - because Theo is an asshole

[arkane1234]

not unclear, just don't do that enough to warrant my care. telnet (popsite) 110 or pine isn't done by me enough. Obviously it's not that tough to figure out.

Could Freenet, GnuNET help here?

[grumbel]

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.

Re:j00 R 0wn3d lol

[Anonymous Coward]

I had a set of Dos 3.1 disks with stoned on them right from the box. Nothing is infallable.

Great!

[Rogerborg]

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?

Re:Great!

[Anonymous Coward]

The difference is that we know Microsoft are up to no good. However there is something very weird about the circumstances in which this issue was raised -- see this post.

Re:Great!

[Anonymous Coward]

Brazenly Trojan Updates?

Where? Who?

Sounds to me like a slashdotter is scared of how this would play against Linux and the OSS movement.

Re:Why aren't people asking as to whom is doing th

[saintlupus]

Who did it? And can they be prosecuted?

Gee, why would you want to do that? I thought everyone who broke into insecure systems was a good-natured Robin Hood, a "white hat" who was just trying to help the poor stupid admins out of the goodness of his or her heart.

Now you're telling me that these people might be malicious?

--saint
(This is the royal "you", of course, referring to the Slashbot Collective. I've got nothing against dfn5 personally.)

Not enough...

[bass_miologics]

I'm sorry but md5 sums aren't enough security for me. I run gentoo and I was taken aback by the announcement. Whats to stop the attacker from placing his own md5 sums on the ftp with the trojaned tarball?

GPG signatures should be incorporated into gentoo.

Re:Not enough...

[kaisyain]

MD5 sums are fine. The problem is that MD5 sums should be treated like PGP keyprints...they have to be transmitted out-of-band of your normal communications or they are (relatively) meaningless.

Re:Not enough...

[Anonymous Coward]

The checksum is stored in /usr/portage/net-misc/openssh/files/digest-openssh -3.4_p1-r3, which comes from rsync, so the attacker would have to compromise the rsync server or do a man-in-the-middle attack, which is harder.

Re:Not enough...

[Charlotte]

Whats to stop the attacker from placing his own md5 sums on the ftp with the trojaned tarball?

The tarball exists on the ftp.freebsd.org site, but the MD5 sum exists in the Gentoo Portage tree. It would only have been a problem if the Gentoo OpenSSH maintainer were to have used the trojaned version and put its MD5 hash in the Gentoo tree (thereby signing it as "ok").

Everything would have seemed to be normal in this case... But still the chances of anything going wrong are slim compared to binary distributions or proprietary software.

Re:Not enough...

[Anonymous Coward]

Correct, but that's not the whole story.

With MD5, you have to transfer the "fingerprint" for each file, whereas with GPG/PGP signatures, you only need to fetch the public key once (and of course you verify the fingerprint over the phone). That way, if you downloaded the pubkey last month, you will still know that that file (or any file) is not signed with the right key. With MD5 the margin is much smaller in that respect.

Is this a good excuse ?

[unixmaster]

People say this is not a fault of OpenBSD because openbsd.org runs on Sun Solaris
I wonder who said that Sun boxes can be owned , they cant be trusted ?
Or I never heard someone say "Oh its solaris it can be hacked"
Or did you ever see Bill G. says : "This site runs on Windows dont blame me!"

Re:Is this a good excuse ?

[unixmaster]

I mean OpenBSD team when I refer to OpenBSD so send your flames to /dev/null ;-P

Re:Is this a good excuse ?

[Anonymous Coward]

Why should I trust OpenBSD if the OpenBSD people wont run it themselves?

Re:Is this a good excuse ?

[Anonymous Coward]

I suppose the real question is: Why is openbsd.org not running OpenBSD? Do they really not have that much confidence in their own software?

Re:Is this a good excuse ?

[Anonymous Coward]

OpenBSD isn't powerful enough to run a major server on.

It only supports one CPU (intel or ppc archs only) *snicker*

This is why I don't use open-source programs...

[ball-lightning]

This is why I'd rather use Windows than Linux. Even though companies like Microsoft HAVE installed some code that monitors you, I know Microsoft won't be snooping in my email account, etc.

Re:This is why I don't use open-source programs...

[hyperstation]

you keep telling yourself that. "microsoft may have access to my email and personal information, but they'd never share that with the government, if they asked" never.

Re:This is why I don't use open-source programs...

[jonabbey]

Neither will the guy who set up this trojan, since it was caught and removed within 6 hours of being inserted.

easynet.be still holds a copy with a wrong md4

[Anonymous Coward]

root@ has been warned.

I wonder if all the people are sleeping.....

no, what we really need

[bass_miologics]

is for the developers to start pgp signing their shit. If someone compromises the machine to where they can replace the tarball with a trojaned one, they can obviously replace the md5 sums also.

That goes for source distributions like gentoo also. What happens if someone puts out a dirty ebuild?

Re:no, what we really need

[Anonymous Coward]

What if the attacker creates bogus private/public keys, signs the archive with the bogus private key, and leaves the bogus public key in a keys file on the ftp server?

Isn't that just as bad as having md5sums on the ftp server, where the solution would be the same? (Solution being this: have many servers which hold the md5sums or pgp keys. They can't -all- be compromised!)

Re:no, what we really need

[gimpboy]

(Solution being this: have many servers which hold the md5sums or pgp keys. They can't -all- be compromised!)

do you really believe this? i mean really, do you believe this? there is _no_ _completely_ _secure_ method for this. this type of compromise is going to happen everyonce in a while. your method will make it harder, but i dont think it will make it impossible. having everyone who wants to peering over the source reduces the possability of it spreading though.

i would urge developers to do what ever is in their power to make distrabution more secure, but remember that there is no completely secure method. there are just better methods.

Re:no, what we really need

[Anonymous Coward]

I meant that as tongue-in-cheek. So my answer is no, I don't really believe "they can't all be compromised".

Re:no, what we really need

[gimpboy]

sorry, it's hard to read that in a comment :)

I think it's okay now

[hardave]

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.

Re:I think it's okay now

[Clue4All]

You FTP server has obviously been compromised, when will it be taken down to be rebuilt?

Re:I think it's okay now

[Anonymous Coward]

They're running it on Solaris, no wonder!

What else is modified?

[Stephen Samuel]

I think that it's just luck that the MD5 checksum wasn't modified along with the tarball. An MD5 sum just verifies the accuracy of the transfer -- not the authenticity of the file. It would be a bit harder to fake the PGP signature (with it's web of trust).

The bothersome thing about this is that someone got into the site (aka: sunsite.ualberta.ca) and managed to modify source tarballs. I'm now wondering:

• what else got modified.?
• was anything modified more completely (less detectably)?
• How did they get in?
• Has the access hole been plugged?

Re:What else is modified?

[Abcd1234]

Heh... the U of A is my old University (just graduated this past April), and what I'm wondering is, how big of a panic are the sysadmins in right now? :)

Re:What else is modified?

[SN74S181]

You raise a point that for some reason everybody here is ignoring.

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:What else is modified?

[T-Punkt]

The MD5 checksum mentioned in the weblog is *NOT* stored alongside the distribution file.
It comes from the package system (or 'ports' in FreeBSD jargon). The package system fetches the tarball from the distribution system and compares its own MD5 checksum against the one calculated from the fetched file.

How to fix this from the site it's calling

[bee]

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.

Re:How to fix this from the site it's calling

[Clue4All]

I think you're unclear on the conecpt of this trojan. Whoever replaced the file wants the machines infect to "phone home" so that he can use them for whatever purpose he has in mind. This wasn't a randomly chosen machine that they're all connecting too, obviously.

Re:How to fix this from the site it's calling

[bee]

No, I understand it perfectly; said code should be ran on the phone-home machine, which itself was a compromised host. The trojan tries to phone home, gets an A from the yes, and aborts.

Re:j00 R 0wn3d lol

[Anonymous Coward]

I did it said the blind man as he smacked his forehead with sheer determination. I hacked ftp.openbsd.org and put a wee little trojan in some code, There are 13 other packages that will automatically rm -rf your entire life on the internet, totalling millions of downloads a day. Prepare the way for windows the new revalution in computing technology!

FYI: Gentoo OK

[jehreg]

Gentoo 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 :-)

Re:FYI: Gentoo OK

[questionlp]

The same is also true with the FreeBSD ports since it checks for the md5 checksum of the file and compares it to the distinfo file located within the port. It is probably also true for the OpenBSD and NetBSD ports collection as well.

Re:FYI: Gentoo OK

[glwtta]

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

I thought the trojan only appeared yesterday?

Re:FYI: Gentoo OK

[doomy]

This is a no-issue.

Logically speaking, every distro you can think of has competent maintainers and or pseudo maintainers (like scripts that install), that does the necessary checking.

But, this necessary checking isn't sufficent. Your gentoo, just like any distribution (Redhat, Debian, Slackware) and *BSD is vulnarable if the MD5's themselves were compromised as well. With modified MD5 sums that give the right sum you're distro needs you would never know the difference between a trojaned file and a non-trojaned file.

Rather, the best way to go about this is to digitally sign the file and educate everyone in the community to use digitial signature checking.

Re:j00 R 0wn3d lol

[Anonymous Coward]

You mean like the Korean Visual Studio.NET CD with Nimda on it?

Yeah, never happens to M$ crap.

Eat a bag of dicks.

I know who DID IT!

[evrim]

look at the snipped trojaned code:
switch(c) {
case 'A':
exit(0);
case 'D':
break;
case 'M':
break;

How many options there? 3
What are they? A,D,M
A+D+M = ADM!!!!!!!!!!!!!!!!!!!!!
They'r back or so ehehe..
Or somebody is using their name. I don't have any chance to confirm this. Anybody?

evrim.

Re:I know who DID IT!

[Anonymous Coward]

Archer Daniels Midland?

I thought that they just trojaned congress...

blocking network traffic

[mborland]

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.

Re:blocking network traffic

[strombrg]

Where, exactly, do you get this stuff about servers having no reason to create outgoing connections to the internet?

I'm guessing you've set up one or two servers, and decided the represent the entire world.

That or you live behind a firewall, and your network guys won't let you touch anything on the outside of it.

(We have hundreds, if not thousands, of servers here that -must- be able to make outgoing connections to the internet. It's the -norm-.)

Re:blocking network traffic

[Abcd1234]

Just OOC, what do these servers do that they need to initiate connections to the outside world? I mean, there's the obvious case of mail servers and DNS servers, but beyond that, I have trouble thinking of a good example. Granted, I haven't had to configure anything exotic, so I may be missing something.

Re:blocking network traffic

[mborland]

First, my post was actually about how defense-in-depth is useful, and how firewalls and local use of iptables play a part of that. If you have thousands of machines connecting to the internet, would you still not benefit from locking down unused ports? No? You want your thousands of machines to make ad-hoc connections directly to the internet? OK, no argument here--you are obviously in control of that situation.

As for 'most' corporate installations, both your DMZ servers and your internal servers should be locked down to only initiate connections specific to their purpose. Shame on those who allow more than that from their servers.

Tip: getting defensive and using Argumentum ad Hominem doesn't make a useful post.

Re:blocking network traffic

[DeputySpade]

Most FTP servers make outbound connections. That's why most FTP clients don't like to work from behind firewalls. DNS servers transfer zones back and forth. Lots of portal websites use scripts to pull data and headlines (like slashdot headlines) off other servers for re-presentation. IRC servers connect to other IRC servers. NTP servers talk to each other. The list goes on and on.

Plus I don't agree with the previous poster's assumption that ssh only lives on servers. I have openssh on all of my workstations so that I can get into them from remote locations for various reasions (retrieving the previous night's work, fetching that MP3 I'm dying to hear, su-ing to root and shuting the box down when I see a thunderstorm on weather.com, etc...)

If he wants to make a broad generalization it might be that you shouldn't compile code on boxes you expect to be secure. I never compile anything on my firewall or my servers. I compile it on my workstation and rsync it over. Of course, even that could be defeated by this makefile trojan since usually the way to install what gets copied over is to make install as root. If this guy had trojaned the 'install' target he would have caught a lot more people with their pants down. Luckily he was either an idiot or only trying to prove a point.

Re:Why aren't people asking as to whom is doing th

[Anonymous Coward]

Turn down that LOGIC STICK. You're blinding me with
your science.

Does this during the "make"?

[StupidKatz]

I might be showing my cluelessness here, but if this is done during the compilation, then this isn't as critical as it might be. I mean, I don't configure or compile any apps as root; so even if there is a remote shell opened on my machine, it only has luser access. (Which still sucks, but is not nearly as bad as a free root shell!)

Friends don't let friends compile as root.

Re:Does this during the "make"?

[greenrd]

even if there is a remote shell opened on my machine

In case you didn't already know this, you can easily check if there is: run netstat -a -n -p|less and check for any suspicious ports or processes. Better still, run pstree -p|less and check for any suspicious processes, whether they're connected to the network or not.

Re:Does this during the "make"?

[1729]

In case you didn't already know this, you can easily check if there is: run netstat -a -n -p|less and check for any suspicious ports or processes. Better still, run pstree -p|less and check for any suspicious processes, whether they're connected to the network or not.

Of course, this assumes that netstat and pstree haven't been replaced with compromised versions.

Re:Does this during the "make"?

[Chexsum]

*cough* The point of this thread is, it isnt as much of a risk if you compile as a non-root user and it can be proven wrong easilly.

The install part of the configure && make CAN copy a pre-made copy of ps/lsof/netstat/ls etc over the original binary. This may also be possible with rpm/deb but I am no expert at how these packages function (itd be good to place added security *ie. this file can replace that type of thing* into the database of packages incase it is possible to overwrite a binary easilly - binary files cannot be trusted completely at any time ;).

The point originally made in this thread isnt exactly a good philosphy to trust but it is definately how you SHOULD configure && make a package, root is for administration purposes only. =)

NB. I put my trust in Debian packages but it is not 100% trust. I also try to not run things as root myself but no-ones perfect.

MOD PARENT DOWN: -1, Troll

[Anonymous Coward]

you are very wrong

[Anonymous Coward]

Look at the gcc-hack the inserted a backdoor into the Linux kernel, and there was NO source code in gcc to do so. It was a self-propogating gcc-miscompile (put there on purpose). Kinda neat actually. I cannot seem to Google the link presently.

theo

[pmf]

"One remote hole in default install, in nearly 6 years". Two if you install new ssh.

Wiped the machine too early?

[_bug_]

It seems if you rebuilt from source and rebooted witihin an hour no time was spent on discovering how the cracker rooted the box in the first place.

If the cracker rooted openbsd.org through this box, then any evidence of the attack would have been wiped, wouldn't it?

Or is there still a chance on finding out who was behind this and how it happened? Firewall logs maybe?

Who are those?

[Anonymous Coward]

Asshole Dickhead Men ?

This indicative of open-source development project

[183771]

I am afraid you are totally wrong, this could happen in open-source enviroments but also in closed development enviroments. The big difference is than i a closed-source project you even do not realise that you have been trojaned!!!

Interesting

[bythescruff]

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

The trojan connects to 203.62.158.32, eh?

> nslookup 203.62.158.32

Server: dns2.intra
Address: 10.16.59.15

Name: snsonline.net
Address: 203.62.158.32

>

Re:Interesting

[Accelerated Joe]

Yeah, and if you'd read the rest of the comment, you'd see that Sarge admits the address refers to his machine. Congrats on exposing the seamy underbelly of the first half of the comment.

Seems like OpenSSH 3.4 trojaned too

[unixmaster]

From freebsd-security mailing list. I am not sure this is for real or fake

I just upgraded my OpenBSD 3.0 machine to OpenSSH 3.4 last night.
I downloaded openssh-3.4.tgz ( notice not p1 ). The MD5 I got was
MD5 (openssh-3.4.tgz) = bda7c80825d9d9f35f17046ed90e1b0a
And look :
[root@superfrink /root/upgrades]# tar -tzf openssh-3.4.tgz | grep bf
ssh/ssh-keygen/bf-test.c
And then:
[root@superfrink /root/upgrades]# head -5
ssh/ssh-keygen/bf-test.c
/* * Blowfish input vectors are handled incorrectly on HP-UX PL.2 systems.
* Perform routine compatability checks. */
#include
So I guess It's not just openssh-3.4p1.tar.gz that is trojaned.
/Chad

Rebuilding from source, and paranoia

[valdis]

Step 1: Read Ken Thompson's Turing Award lecture "On Trusting Trust"

http://www.acm.org/classics/sep95/

Step 2: Decide for yourself if you're ready for the tinfoil-helmet brigade.

Step 3: Type 'make world' if you dare.

This is why I didn't trust...

[realdpk]

...and don't trust the OpenSSL advisory sent out to Bugtraq by a "Ben Laurie". It's not signed, so I can't show that he wrote it. Apparently, it's trivially possible to get a trojaned tarball installed in mirrors everywhere, so that it is mirrored on "official" sources does not help. Is there any reason to believe the OpenSSL advisory other than its mention on their webpage (which could also be hacked as they're running Apache 1.3.6 which could have the chunked bug?)

(this has turned in to quite the rant. sorry. :)

OpenBSD: Security Through Hype

[Anonymous Coward]

Sure security threw obscurity is bad, but OpenBSDs method is worse.

OpenBSDs method of security through hype does nothing at all.

Well except get alot of people to order CDs for a mediocre UNIX clone and falsely believe they are secure...

public key authentication

[gimpboy]

another more likely possability would be that he was using passwordless authentication. so by rooting a box he has access to, the cracker could ssh to any other computer/user with his public key in the authorized_keys file. they could also scp the trojaned file in the same manner. this is not very unlikely.

Re:This indicative of open-source development proj

[f00Dave]

I am afraid you are totally wrong, this could happen in open-source enviroments but also in closed development enviroments. The big difference is than i a closed-source project you even do not realise that you have been trojaned!!!

And how am I "totally wrong"? The timebomb I described *was* a closed-source project. Closed-source doesn't meant no-source, it merely means that the access to it is limited to some extent.

Knee-jerk reactions like yours don't help the 'cause' of Open Source development. Next time please take a deep breath and think about how your post will be interpreted before you send it. Thanks.

OpenBSD security model

[Anonymous Coward]

We all know the security plan "Security through obscurity" it's not good.

But openBSD is based around a worse and less known plan: "security through hype".

Just keep screaming that it's the most secure and cover up any embarrasing security problems and people will just start to believe it.

It's what's known as the "big lie" tactic. Just say the lie enough times and eventually people will start to believe it. Seems stupid but in history there are several examples of this working on a large scale. So why not use it to sell a bunch of CDs?

(OpenBSD is for-profit organization, another little tidbit money grubbing hype promoting theo likes to keep under wraps.)

OpenBSD is securiy through hype.

The website says no hole in the "default" install in 6 years? Well it _must_ be secure then! Oooh hey look microsoft servers have a 99.999% uptime to! oh what a wonderful world where the marketing hype rings true! yippy!

OpenBSD is all about keeping up it's image and feeding theos ego, that's about it.

too many assumptions..

[gimpboy]

too many people are making assumptions. all we know is that the machine was wiped and reinstalled. he could have backed alot of relivent info before he wiped it. this would allow him to fix the computer, get it back up, and inspect the info later at his leisure.

i would wait until more information is available before jumping to what i would consider to be a silly conclusion.

Re:too many assumptions..

[Anonymous Coward]

Not really. He would have mentioned it if he backed it up. Why hide such a thing? Also, the machine was not "wiped and reinstalled". It was rebuilt from source code - source code that he possibly did not verify, and using a toolchain that was possibly backdoored. Rebuilding does no wiping, nor does it do any reinstalling in the "installing an operating system" use of the word, which you seem to be using.
If you still don't understand, go read about "make world" in the FreeBSD handbook, or "make build" (and now the lovely build.sh) in the NetBSD documentation.

Re:too many assumptions..

[gimpboy]

who said he is hiding anything? because he doesnt state something explicitly doesnt mean he is hiding. perhaps he is assuming that other people would assume he made backups.

It was rebuilt from source code - source code that he possibly did not verify, and using a toolchain that was possibly backdoored.

another assumption that i dont think you can accurately make, but hey i cannot stop you.

False sense of security

[Anonymous Coward]

Checking the md5sum just means the package matches the checksum. No good if the intruder updates the md5sum file. At least if there's an OpenPGP signature they have to compromise the private key first.

Re:Why aren't people asking as to whom is doing th

[arkane1234]

Gee, why would you want to do that? I thought everyone who broke into insecure systems was a good-natured Robin Hood, a "white hat" who was just trying to help the poor stupid admins out of the goodness of his or her heart.

Enough sarcasm, this *was* malicious simply because this could have been a setup for a DDoS attack.

Theres a big difference between breaking into a system then reporting the issue to the admin, and breaking into a system via a trojaned makefile/config only to gain root/user shell access for no other reason than to use them for some other purpose.

now you know the difference between black hat, and white hat.
of course then you have those individuals that make tools that encompass an entire OS, leaving the original interface a complete mystery to the user. These hackers are known as red hat :) *sorry, joke*

Trolling for karma, eh?

[Inoshiro]

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.

Re:Trolling for karma, eh?

[wfrp01]

The only person using the word "eerily" is you. By Theo's own admission, Alan wrote him an email indicating that some people don't trust him. That's very different from what you state - that he simply didn't like the way Theo was handling things.

Whether or not Alan overstated his case is subject to debate. But what Theo said Alan told him is not. That is why having the complete text of Alan's email would be interesting. Or would you rather argue your position from a position of ignorance?

Re:Trolling for karma, eh?

[Anonymous Coward]

Why the hell did he mention it in that context then?
I would suspect a programmer such as Alan to a bit better to understand the importance of context; in fact, I strongy believe that Alan was being a complete arse on purpose.

Re:Trolling for karma, eh?

[HiThere]

Without having read the letter, or any of the rest of the discussion between them, it's quite clear that Theo and Alan were having a bit of an argument. Alan overstepped the bounds of civility, but we don't really know what kind of provocation he was subjected to. And Theo doesn't exactly have the reputation as inspiring mild mannered discussions.

Also, Alan didn't decide that this needed to be dragged out into public, and Theo did. So it is up to Theo to prove that he was justified.

And all of this is totally unrelated to the current problem. I.e., how to let everyone who updated the code with the wrong version be warned that they need to update it again.

Where are the public keys?

[Anonymous Coward]

The md5sums are not enough. Someone trustworthy[1] should
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/pu bl ickey.html

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.

Re:Where are the public keys?

[TeddyR]

Yup... I prefer at least two of the following sources myself:

1- Web site

Problem: Sites can be easily "defaced"

2- Hard Media (CD)
Problem: Getting the physical media itself

3- Public Keyserver
Problem: hopefully the key is uploadted legitimatly first.

4- Fingerprint verifiable by someone answering the regular, publicly advertised phone system number
Problem: most receptionists dont know what PGP/GPG is.
Problem: Long distance... {calling .AU from .US}

What I am really surprised has not happened is to have the major security signing bodies get together and sign each others keys.

That way for example if I am able to verify redhats key through one of the above methods, then if I get something signed with an "openssh" project key it would show up as valid... [remember that old "web of trust" idea]?

Re: Debian signed packages

[183771]

Also apt seems to have signed packages, but seems to be not widely used, as you can see here: http://www.kitenet.net/~joey/pkg-comp/#foot1

Old .gz file is OK too

[SaDan]

I downloaded the portable version of OpenSSH 3.4p1 pretty much as soon as it was released from ftp.openssh.com, and it's got the correct MD5 sum.

The timestamp on my copy of the openssh-3.4p1.tar.gz file is June 26th.

Anyone know when the trojan file was put in place?

Re:Old .gz file is OK too

[Anonymous Coward]

"1. Systems affected:

OpenSSH version 3.2.2p1, 3.4p1 and 3.4 have been trojaned on the
OpenBSD ftp server and potentially propagated via the normal mirroring
process to other ftp servers. The code was inserted some time between
the 30th and 31th of July. We replaced the trojaned files with their
originals at 7AM MDT, August 1st."

-coldfire

Re:j00 R 0wn3d lol

[BitHive]

Can you give more info about the necessary measures to prevent an XP box from phoning home? I have an OpenBSD firewall at my disposal, and love to take a look at what my workstation is trying to do.

Right...

[vsprintf]

This is the md5 checksum of the openssh-3.4p1.tar.gz in the FreeBSD ports system: ...

This is the md5 checksum of the trojaned openssh-3.4p1.tar.gz:...

And we know you're not the cracker, and we should believe you because ... oh, it's posted on /. so it must be true.

Re:Right...

[Anonymous Coward]

We know because it's open source and can verify it for ourselves. Dumbass.

Re:Right...

[John Sullivan]

Well, what do you expect from someone whose own /. username is vulnerable to buffer overflow attacks?

Post-mortem?

[flacco]

Do we know yet:

• Who did it
• How they did it
• How we can prevent a recurrence
• How much pain a trojan-writer can stand before giving up the ghost?

gah!

[Anonymous Coward]

Do these titles bother anyone else? When I read "OpenSSH Package Trojaned" I feel a NEED to read up on it and figure out exactly where the trojan is and what might be affected. But then in the comments it says oh, its not really a trojan, just a hack. Can we please stop with these threats of terror, haven't we all had enough by now? And no we don't care how much it sells.

Bad news and Good news

[Sloppy]

OpenBSD's reputation has taking a bit of a beating lately, but a lot of it has been mostly superficial. The recently-found bugs in OpenSSL and OpenSSH don't really bother me a lot. Programming mistakes happen, and it looks like they're getting found. (Whether they're being found as part of the auditing process or because someone got bitten and was investigating why it happened, I don't know. I haven't looked into it.) And when they're getting found, fixes are being distributed lightning fast.

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:Bad news and Good news

[Anonymous Coward]

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.

Reasons:

- lack of a good GUI.
- lack of complete integration with popular email programs (especially Windows programs such as Outlook Express).

People are lazy. Until encryption is nearly transparent, they aren't going to use it for email.

Re:Bad news and Good news

[glwtta]

yes, very "insightful":

And it looks like they're not "eating their own dog food," and eating Sun dog food instead

did you ever think there might a reason for that?

then you can't trust a web server to give you a web page with an unaltered MD5 sum. Surely this is common sense?

I am not sure, but this just might be the reason why systems like BSD ports and Gentoo portage store the MD5 sums in the ports trees, and don't in fact get them from websites.

The real solution is digital signatures (i.e. an MD5 sum encrypted with a private key).

WOW! what an original and fresh solution! you sir, are some sort of genious for coming up with this.

congratulations, you've managed to regurgitate several of the things that have been said, literally, hundreds of times today already. I think the Society for Prevention of Cruelty to Dead Horses might have a bone to pick with you.

Re:Bad news and Good news

[Sloppy]

I am not sure, but this just might be the reason why systems like BSD ports and Gentoo portage store the MD5 sums in the ports trees, and don't in fact get them from websites.

I haven't used Gentoo portage yet, but in the case of OpenBSD ports, well... I haven't been buying CDs. I just "buy" a donation, and then do a FTP install. So my downloaded ports could potentially have tampered-with MD5s. But you've got a point; people who install from CD should have pretty safe ports.

WOW! what an original and fresh solution! you sir, are some sort of genious for coming up with this.

Take it easy, buddy, I didn't claim I was being clever. Right above that in my post, I think I mentioned it was common sense.

You'll also see more than a hint of advocacy in my post. The last thing I want is people like you coming up with reasons for GPG not being necessary. So Shhhhhhhh, ok?

Re:Bad news and Good news

[Anonymous Coward]

A Balanced and experienced opinion, rare to find these days.

I'm not here to critisise (oops spelling has given my nationality away a bit), but I wonder
if cryptograpthy and signing (hashing/checksum) of
entities might not be the only answer (not saying that was what you were saying) in this case. For example, being away from the keyboard after an authenticated session/encrypted tunnel et-al, leaves trust (CIA) down to human falability (its late I've just got back from the pub/restaurant/with friends).

Some kind of chain of peer review, needs to be incorporated, where falability is acountable.

Hmm, I think I've been staring at breasts for too long.

Probably missed my original train of thought.

Nice, top, comments Sloppy.

Cheers.
Anon UK.

Re:Bad news and Good news

[glwtta]

I just "buy" a donation, and then do a FTP install

CDs aren't quite what I meant - the portage tree is maintained by the Gentoo team, separately from any of the ftp mirrors you use for the package downloads (updated via rsync, incidentally). So for the attack to succeed, not only do the ftp mirrors have to be compromised, but also the Gentoo tree (and then the attacks would still be caught by the FreeBSD, OpenBSD, etc, rather quickly) Certainly this system isn't impregnable, but there's enough redundancy here to make successful attacks rather difficult.

Don't get me wrong, I'm all for PGP signatures, it's just that out of the 500+ posts in this thread, around 2/3 have mentioned it, it's probably enough advocacy for one day :)

It's a great idea, though will only work effectively if the checking is done automatically by systems like Portage; and I'm sure it will be implemented not that long from now, it's not like the guys who write this software know less about security than we do ;)

On the Eve of Defcon. Coincidence?

[Anonymous Coward]

Hmm. An extremely easy-to-spot (read dumb) trojan appears on the eve of defcon. The attackers had the wherewithall to get a compromised package onto the OpenBSD machines, but did so in a way that basically guaranteed it would be discovered quickly.

Doesn't this seem a little odd?

Looks like a play to discredit OpenBSD. Not to actually infect machines.

Re:This was not our fault

[Anonymous Coward]

So, it's NetBSD - but more so: why DID A FREEBSD USER found the trojan, and not a OpenBSD user? Eh?

The original binary was replaced

[Anonymous Coward]

The server hosting the file was compromised somehow.

There was no code submission oversight, nor is there likely to ever be one.

Re:The original binary was replaced

[SN74S181]

Binary? Everybody here is talking about source code.

Gentoo is Good to Go

[FreeUser]

I thought the trojan only appeared yesterday?

I don't know when the trojan appeared exactly, but as one who uses Gentoo at both work and at home, I can attest to the following:

• Gentoo mirrors the source tarball at ibiblio and elsewhere, the current ssh being 3.4p1
• The MD5sum for the Gentoo ebuild is correct
• The mirrored tarball is also correct
• I've had no trouble installing the current openssh over the last several days
• I have personally verified the md5sums on each machine, not one of them contained the trojaned version, confirming that Gentoo's ebuild system did in fact correctly check the md5sum, had the correct md5sum, and had the correct source tarball.

We still need to have each ebuild, and IMHO each tarball, GPG signed by the appropriate developer, with separate third party trusted sources for the public keychain (and the ability to purchase the keychain on CD-Rom from trusted sources for the ultra-paranoid). I've been grousing about this off and on for over a year now (in Debian, later Source Mage, and now Gentoo, all of which need to address this. Maybe now they will.)

Re:Gentoo is Good to Go

[glwtta]

Maybe now they will.

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:This was not our fault

[singollo]

-- This never would have happened if someone in our development group hadn't been irresponsible enough to install NetBSD on that CVS machine.

Well, then it is your fault. Flaming NetBSD doesn't change the fact that someone associated with OpenBSD made an error in judgement.

N.B. I use and love OpenBSD, but I also expect people (including myself) to 'fess up to thier mistakes.

Re:This was not our fault

[Anonymous Coward]

lest it's not obvious:

(a) the poster is not who he says he is.
(b) this is completely untrue.
(c) his slashdot account should be terminated.

Re:203.62.158.32 (because)

[Wouter Van Hemel]

Besides, why does it connect to the ircd port?

Probably because they hope it won't raise much suspicion. Using 1337, 31337, etc would be like waving a flag.

If it'd be up to me, I'd use one of the less known ip protocols.

Re:This was not our fault

[Dahan]

Oh, like we should all believe some Anonymous Coward... it's well-known that Theo has a grudge against the other BSDs, especially NetBSD... I remember when he was threatening to crapflood the NetBSD and FreeBSD mailing lists through an anonymous remailer.

OpenSSH.org's Advisory

[lagoon]

Check out http://www.openssh.org/txt/trojan.adv

Re:How many people do check the MD5 checksum-wrong

[Wouter Van Hemel]

It only shows how many people _who are interested in your packages_ check the md5/pgp key.

I don't think most servers, especially important and secure ones, run a mp3/ogg streamer. That would be home users, mostly. Joe 'admin' Sixpack. And well... 'nuff said.

Use SSH.com's software...

[BalkanBoy]

as I do on my private Linux box, and you don't get this type of crap, nor the last security hole related to OpenSSH, which never did exist in the non-commercial SSH.com version which is free for all to use for non-profit(evaluation) purposes. It is freely available for download through SSH.com (source or binary I believe). One too many goofs with OpenSSH recently...as far as I'm concerned. Maybe I'm paranoid... but so what? So is everyone else.

OpenSSH - The new wuftpd.

[Anonymous Coward]

OpenSSH has had quite a few security flaws lately and this just hurts it more. ssh from ssh.fi is much better. No 2,000 dependancies, a much better security history, and its all ssh2. OpenSSH is the new sendmail/wuftpd, but nobody wants to admit it.

#include <expletive.h>

[ewhac]

I just rebuilt OpenSSH-portable yesterday on my FreeBSD box, finally getting around to addressing the newest vulnerabilities in 3.3.

I did a cvsup of the entire ports tree, then built OpenSSH-portable-3.4p1 as root. The build went fine; no MD5 checksum problems were reported. Did I get in just after the problem had been fixed, or am I screwed?

BTW, pkg_info now reports that I have openssh-portable-3.4p1 installed alongside openssh-portable-3.3 (the last version I built from ports). Is this a problem? If so, how do I fix it?

Schwab

Re:Oh my!!!

[Anonymous Coward]

Micro$hit?

Re:This was not our fault

[MrDoran]

hi, anonoymous coward here.

if you research the user who posted that comment, you'll find that (s)he is not in fact Mr de Raadt.

Re:This was not our fault

[glwtta]

cute.

THIS IS NOT THEO

[cperciva]

If you look at the parent author's posting history, you'll see that he is nothing more than a troll who fools people into thinking that he is Theo. (Incidentally, the name is "Theo de Raadt", not "Theo DeRaadt".)

Please mod the parent into oblivion.

Re:THIS IS NOT THEO

[mwalker]

If you look at the parent author's posting history, you'll see that he is nothing more than a troll who fools people into thinking that he is Theo. (Incidentally, the name is "Theo de Raadt", not "Theo DeRaadt".)

Look, this whole FreeBSD/OpenBSD flamewar has gotten out of hand. It's bad enough that you people are blocking each other's email, but let's not go accusing Theo of stealing his own account. Yes, a FreeBSD box was responsible for this security breakdown. Deal with it. There's no reason to go spreading wild accusations like this.
That's Theo's Slashdot account. Quit being a jerk.

-norm- my ass

[Anonymous Coward]

repeat: norm, my ass.

Theo,

[Anonymous Coward]

you spelled your name wrong!

OBSERVATION

[applejacks]

Slashdot : - : A load of shit monkeys who think they are professional experts because they were able get a slashdot account and use a string of words with letters longer than 7 characters in a sentence that sounds remotely coherent.
1.Usually found downloading pornographic material and spending all week downloading upgrades.
2.Rarely if ever contributes original ideas or projects. See (1); Too busy upgrading.

List Of Servers

[Myuu]

Hopefully, this has already been posted by the orginal emailer, but Tomi Nylund posted a list on bugtraq list with a list of affected servers.

"Anyways, we did some research here at Oulu regarding the propagation of
the
trojaned OpenSSH-3.4p1.tar.gz, and found out the following:

Trojaned mirrors:

3ac9bc346d736b4a51d676faa2a08a57
MD5
(./ftp.club-internet.fr/pub/OpenBSD/OpenSSH/port ab le/openssh-3.4p1.tar.gz)=
3ac9bc346d736b4a51d676faa2a08a57
MD5(./ftp.easynet.be/openssh/portable/openssh-3. 4p 1.tar.gz)=
3ac9bc346d736b4a51d676faa2a08a57
MD5(./ftp.freenet.de/pub/ftp.openbsd.org/pub/Ope nB SD/OpenSSH/portable/openssh-3.4p1.tar.gz)=
3ac9bc346d736b4a51d676faa2a08a57
MD5(./ftp.fsn.hu/pub/OpenBSD/OpenSSH/portable/op en ssh-3.4p1.tar.gz)=
3ac9bc346d736b4a51d676faa2a08a57
MD5(./ftp.inet.no/pub/OpenBSD/OpenSSH/portable/o pe nssh-3.4p1.tar.gz)=
3ac9bc346d736b4a51d676faa2a08a57
MD5(./ftp.isu.net.sa/pub/mirrors/ftp.openbsd.org /p ub/OpenBSD/OpenSSH/portable/openssh-3.4p1.tar.gz)=
3ac9bc346d736b4a51d676faa2a08a57 MD5
(./ftp.jaquet.dk/pub/openSSH/portable/openssh-3. 4p 1.tar.gz)=
3ac9bc346d736b4a51d676faa2a08a57
MD5(./ftp.openbsd.cz/pub/OpenBSD/OpenSSH/portabl e/ openssh-3.4p1.tar.gz)=
3ac9bc346d736b4a51d676faa2a08a57
MD5(./ftp.openbsd.org.br/pub/OpenBSD/OpenSSH/por ta ble/openssh-3.4p1.tar.gz)=
3ac9bc346d736b4a51d676faa2a08a57
MD5(./ftp.openbsd.ru/pub/OpenBSD/OpenSSH/portabl e/ openssh-3.4p1.tar.gz)=
3ac9bc346d736b4a51d676faa2a08a57
MD5(./ftp.sajinet.com.pe/pub/OpenBSD/OpenSSH/por ta ble/openssh-3.4p1.tar.gz)=
3ac9bc346d736b4a51d676faa2a08a57
MD5(./ftp.stealth.net/pub/mirrors/ftp.openssh.co m/ pub/OpenBSD/OpenSSH/portable/openssh-3.4p1.tar.gz) =
3ac9bc346d736b4a51d676faa2a08a57
MD5(./ftp.tku.edu.tw/pub/OpenBSD/OpenSSH/portabl e/ openssh-3.4p1.tar.gz)=
3ac9bc346d736b4a51d676faa2a08a57
MD5(./ftp.uninett.no/pub/OpenBSD/OpenSSH/portabl e/ openssh-3.4p1.tar.gz)=
3ac9bc346d736b4a51d676faa2a08a57
MD5(./ftp.volftp.mondadori.com/mirror/openbsd/Op en SSH/portable/openssh-3.4p1.tar.gz)=
3ac9bc346d736b4a51d676faa2a08a57
MD5(./ftp7.usa.openbsd.org/pub/os/OpenBSD/OpenSS H/ portable/openssh-3.4p1.tar.gz)=
3ac9bc346d736b4a51d676faa2a08a57
MD5(./hal.csd.auth.gr/mirrors/OpenSSH/portable/o pe nssh-3.4p1.tar.gz)=
3ac9bc346d736b4a51d676faa2a08a57
MD5(./openbsd.csie.nctu.edu.tw/pub/OpenBSD/OpenS SH /portable/openssh-3.4p1.tar.gz)=
3ac9bc346d736b4a51d676faa2a08a57
MD5(./openbsd.nsysu.edu.tw/pub/OpenBSD/OpenSSH/p or table/openssh-3.4p1.tar.gz)=
3ac9bc346d736b4a51d676faa2a08a57
MD5(./openbsd.rug.ac.be/pub/OpenBSD/OpenSSH/port ab le/openssh-3.4p1.tar.gz)=
"

Who changed the source code and how?

[Bob Loblaw]

Was it some cracker using a root exploit in OpenSSH? ;]

Seriously though, does anyone know how it happened yet? I have seen lots of talk about the trojan but nothing about how the trojan got there in the first place. This seems like it could be the tip of the iceberg.

OpenBSD fah down go boom

[Anonymous Coward]

Looks like yet another fuckup by OpenBSD. I wonder what Clintonesque
turn-of-the-phrase Theo will spin this one with!

Open BSD - no exploits since the last full moon in an 'r' month'

I've done things like that.

[jc42]

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

This sounds like a fairly conventional sort of debug hook. Connect back to the source archive where there are lots of debug and alpha-release goodies, let the installer download stuff, and compile it all into the binaries. Just what you'd want when you're developing stuff and want to make it easy to install on test machines.

I've also sometimes forgotten to remove the debug hooks.

Re:I've done things like that.

[Chexsum]

Programmers who put backdoors in their programs are crackers!

Re:I've done things like that.

[jc42]

Well, the metaphor that I prefer is the construction one: To do a good job of building something, whether it be a building or a program, you need to include a lot of scaffolding. You remove most of it when you're done. But with software, you can be slow about this, since the scaffolding is generally not too visible, and you invariably find that you need it when the user bug reports come pouring in.

If that makes me a cracker, well, I and all other good programmers are crackers.

Of course, I do like to document my "back doors" in the user manual. I've learned that this can save me some time. Instead of a customer calling up and saying "It doesn't work and it won't tell me what's wrong" they often look at the manual. They find the instructions for turning on the debug hooks, so they do it, direct the output to a file, and email it to me. We just skipped over the first phase of fixing their problem and went right to the second.

And sometimes the output tells them why it was failing. They move the config file to one of the places where it was looking, and change the permissions so the file can be read, and it works without even bothering me.

So a documented "back door" is even more useful than an undocumented one.

Re:I've done things like that.

[Chexsum]

You could have explained 'what you do too' instead of saying just "I do that too" when the article is about having a program open a root shell for its 'creator' to access. Having debugging in your program is of course the practise of the art.

Now I know you were talking about 'easter eggs'. An easter egg is alot less offensive than a common (?) trojan. You are not a cracker after-all. why didnt you pick the confusion up and reply saying you were talking about 'easter eggs'? :P

Bunch of Arse

[Anonymous Coward]

I respect OpenSource, I also appreciate spending money. Not to confuse the two, but, one wonders whether or not we should trust, to much, the whim of the written word on the net.

Are you really there, all of you, can you prove you exist and are not just some spamming, turing test/machine type thing?....

History keeps repeating itself (new 0day exploit?)

[kemikalzen]

No, this is _not_ flamebait, just my 2 cents :-)

Is there a new "blackhat" 0day exploit circulating that never appeared on Bugtraq ?

This is the second time the obsd-team is being targetted by hackers unknown, the first time with an unexpected exploit in Apache with a followup-0wning of monkey.org and subsequent backdooring of the dsniff/fragrouter sources (which i'm sure everybody knows about by now), and now the OpenSSH sources gets backdoored, and somebody in the obsd-team will vigourosly defend their honor and will claim that some local exploit was used to gain access. C'mon, i'm sure these security-minded people will have their system secure...

History keeps repeating itself..

Safe SSH

[Izanagi]

I am glad to hear that nerds are using protection during SSH. The fear of STDs is a major factor these days, especially with multiple partners.

Hooray for OSS!!!

[Anonymous Coward]

Hooray for OSS!!!

This incident was bound to happen.

[Anonymous Coward]

I don't want to write a book here, so I'll keep this short...

It has been known for quite some time that the OpenBSD dev boxes (cvs/www.openbsd.org, etc) have been comprimised. This incident didn't surprise me in the least.

I'm not trying to be a troll, but whenever you say you're OS is "the most secure one available" or something of the like, you're going to become a target of blackhats (apache and openssh remote root).

I guess the bottom line is, don't become cocky about your security!

who is guarding the guards...

[TurdFurgeson]

HAHAHAHHAHAHAHAHHAHA - the fags at zdnet didnt post this story. losers.

The odds are just to high to be coincidence.

[tallackn]

Work with me on this one.

The release is trojaned.

The first guy to be openly curious about it in the wild is Mav. Out of the tens of thousands that might have gotten it alredy.

Mav goes and seeks input from his mate Sarge.

Sarge just happens to be the owner of the box that is the callback for this trojan.

Mav posts to slashdot, giving some of the discovery credit to Sarge.

I am just asking, exactly how unlikely do the odds have to be before you got to accept that it is obviously something more than freak coincidence.

Nathan...

Re:The odds are just to high to be coincidence.

[Anonymous Coward]

a high percentage of australian admins would be sitting in #sage-au (since thats who it is for). had the evil daemon (on sarge's machine) been hosted on a wide range on other australian servers, odds are that one or more of that servers admins should have been sitting in channel and piped up at the mention of their precious little networks.

im sure there is life outside of conspiracy theories.

What about the Cygwin binary

[GekkePrutser]

Hi Everyone!

Does anyone have an idea whether the cygwin sshd is affected? 3.4p1 is the current version, and they may have built it based upon the trojaned source. I don't know where these guys get their source from.

GekkePrutser

203.62.158.32 is still online

[herbierobinson]

It answer inverse DNS with "203.62.158.32".

Another "OBSERVATION"

[Anonymous Coward]

applejacks : a-puhl-jackz : A shitmonkey who thinks he is witty and insightful because he was able to get a slashdot account and use a string of words longer than 7 characters in a sentence that sounds remotely coherent.

1. Usually found staring at http://goatse.cx/hello.jpg and pounding his fat, sticky fingers on his keyboard to share "LOL"s with his fellow AOL lusers.
2. Rarely if ever contributes on-topic discussion. See (1); lacks a two-digit number of brain cells.

Re:Another "OBSERVATION"

[applejacks]

ahem, never have i used the three letter expression L O L, and my fingers are quite small. And besides I star at http://www.pimpworks.org/oof.jpg

Re:Slashdot Effect

[AjR]

WHo's the Larry Niven fan then?

Yes and No

[FreeUser]

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.

Yes, and No.

Yes, in that it showed the strength of free software's openness with information, such that as soon as one person noticed something funny, the news got out and the trojan averted.

No, because in fact we just got really, really lucky. If the MD5sum hadn't been located on a different (uncompromised) server, the attacker(s) could have changed the MD5sum as well, and it might have been weeks, months, or longer before anyone noticed. My bet is on weeks, since someone would have poked at the code, but one can never be sure.

In other words, the current approach didn't really work, it just got lucky. MD5sums are great for identifying corrupt data or incomplete downloads, but they are neither designed for, nor good at, identifying hostile, deliberate sabatage.

GPG signatures, on the other hand, combine the strengths of MD5sums with the ability to immediately recognize a file that has been placed in an archive by someone other then the recognized, official developer, and would have prevented this entire thing regardless of where the signature is located (assuming the keys themselves are properly managed: available on multiple, independent keyservers, downloadable from multiple archive sites like ibiblio, etc., and available for purchase on CDROM for the ultra-paranoid).

Re:Yes and No

[glwtta]

um, the current approach is that the MD5 sums are stored on a separate server, many separate servers, in fact. I have nothing against PGP signatures, I'm just saying there's really no need to get hysterical - the current system is still pretty damn difficult to get around.