OpenSSH Package Trojaned

MD5 sums by cheezycrust · 2002-08-01 00:16 · Score: 5, Informative

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

--
Teenagers these days don't have as much sex as they want each other to think they do.

Re:MD5 sums by karmawarrior · 2002-08-01 00:55 · Score: 3, Informative

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

--
KMSMA (WWBD?)
Re:MD5 sums by jaavaaguru · 2002-08-01 02:53 · Score: 1

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.

--
Follow me
Re:MD5 sums by bracher · 2002-08-01 03:03 · Score: 1

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 by karmawarrior · 2002-08-01 03:41 · Score: 1

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*

--
KMSMA (WWBD?)
Re:MD5 sums by HiThere · 2002-08-01 09:26 · Score: 2

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

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

--

I think we've pushed this "anyone can grow up to be president" thing too far.
Re:MD5 sums by nobody/incognito · 2002-08-01 10:57 · Score: 1

can i get a binary for that? JUST KIDDING!!! sheesh. nobody

--
parturiunt montes, nascetur ridiculus mus

203.62.158.32 by bsDaemon · 2002-08-01 00:17 · Score: 1

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 by CrazyDuke · 2002-08-01 00:24 · Score: 3, Insightful

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.

--
Any sufficiently advanced influence is indistinguishable from control.
Re:203.62.158.32 by jorleif · 2002-08-01 00:26 · Score: 2, Informative

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 by Dark+Lord+Seth · 2002-08-01 00:32 · Score: 1

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

--
Hate me!
Re:203.62.158.32 by jorleif · 2002-08-01 00:34 · Score: 2, Insightful

Except if the port was closed recently when this whole thing came out?
Re:203.62.158.32 by Anonymous Coward · 2002-08-01 00:47 · Score: 5, Interesting

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 by JPriest · 2002-08-01 00:59 · Score: 2, Insightful

What exactly are the odds of that?

--
Saying Java is nice because it works on all OS's is like saying that anal sex is nice because it works on all genders.
Re:203.62.158.32 by Kruemelmo · 2002-08-01 01:37 · Score: 1

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 by Anonymous Coward · 2002-08-01 01:37 · Score: 1, Informative

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 by Anonymous Coward · 2002-08-01 02:03 · Score: 1, Informative

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 by Null+PTR+for+Lunch · 2002-08-01 02:19 · Score: 1

I'm willing to be a zillion people are portscanning that IP right now...
Re:203.62.158.32 by _bug_ · 2002-08-01 02:23 · Score: 1

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 by Bostik · 2002-08-01 02:29 · Score: 3, Informative

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.

--
There is no such thing as good luck. There is only misfortune and its occasional absence.
Re:203.62.158.32 by dirtyhippie · 2002-08-01 02:39 · Score: 2, Informative

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 by cheezfreek · 2002-08-01 03:02 · Score: 1, Funny

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 by adam613 · 2002-08-01 03:06 · Score: 3, Informative

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 by _bug_ · 2002-08-01 03:12 · Score: 1

... 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 by dossen · 2002-08-01 03:39 · Score: 3, Informative

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 by stux · 2002-08-01 05:04 · Score: 2

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

--

---
Live Long & Prosper \\//_
CYA STUX =`B^) 'da Captain,
Jedi & Last *-fytr
Re:203.62.158.32 by Skapare · 2002-08-01 06:59 · Score: 2

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

--
now we need to go OSS in diesel cars
Re:203.62.158.32 by Lorens · 2002-08-01 07:21 · Score: 1

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 by ndecker · 2002-08-01 07:35 · Score: 1

^Sarge^ is not talking about recompiling the system. AFAIK the RedHat install was replaced by FreeBDS.
Re:203.62.158.32 by frost22 · 2002-08-01 08:42 · Score: 2

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

--
...and here I stand, with all my lore, poor fool, no wiser than before.
Re:203.62.158.32 by nobody/incognito · 2002-08-01 11:04 · Score: 1

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

--
parturiunt montes, nascetur ridiculus mus
Re:203.62.158.32 by nobody/incognito · 2002-08-01 11:19 · Score: 1

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

--
parturiunt montes, nascetur ridiculus mus
Re:203.62.158.32 by millette · 2002-08-04 19:17 · Score: 1

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

hmmm.... by reaper20 · 2002-08-01 00:17 · Score: 4, Funny

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

Re:hmmm.... by Chester+K · 2002-08-01 00:22 · Score: 4, Funny

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!

--

NO CARRIER
Re:hmmm.... by ndecker · 2002-08-01 00:27 · Score: 4, Informative

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.... by archen · 2002-08-01 00:33 · Score: 1

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.... by Y+Ddraig+Goch · 2002-08-01 00:41 · Score: 1

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.

--
Meddle thou not in the affairs of Dragons, for thou art crunchy and with most anything.
Re:hmmm.... by Dwedit · 2002-08-01 01:06 · Score: 1

Nope, just sticking Nimda in some asian country's Visual Studio .Net.
Re:hmmm.... by NumberSyx · 2002-08-01 01:07 · Score: 2, Insightful

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.

--
"Our products just aren't engineered for security,"
-Brian Valentine,VP in charge of MS Windows Development
Re:hmmm.... by IXI · 2002-08-01 01:07 · Score: 1

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?

--
He saw some dirty arabs and fired. Too bad it was just some friendly kurds, BBC reporters and his fellow cowboys.
Re:hmmm.... by hardcampa · 2002-08-01 01:20 · Score: 1

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.... by zapfie · 2002-08-01 01:30 · Score: 1

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

--
slashdot!=valid HTML
Re:hmmm.... by PyromanFO · 2002-08-01 01:43 · Score: 1

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.... by ThereIsNoSporkNeo · 2002-08-01 02:01 · Score: 2, Funny

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.

--
With my dying breath, I curse Zoidberg!
Re:hmmm.... by alienmole · 2002-08-01 02:02 · Score: 1

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.... by Stephen+Samuel · 2002-08-01 02:15 · Score: 2
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!
--
Free Software: Like love, it grows best when given away.
Re:hmmm.... by Anonymous Coward · 2002-08-01 02:23 · Score: 1, Insightful

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.... by phorm · 2002-08-01 03:00 · Score: 1

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.... by scottj · 2002-08-01 04:35 · Score: 1

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.... by homer_ca · 2002-08-01 04:57 · Score: 2

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.

Since its only a build issue... by LT4Ryan · 2002-08-01 00:18 · Score: 2, Interesting

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

--
Macs as a fetish property

Re:Since its only a build issue... by Fluffy+the+Cat · 2002-08-01 00:25 · Score: 3, Informative

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... by Hater's+Leaving,+The · 2002-08-01 01:27 · Score: 1

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.

--
Keeping /. cynic density high since the fscking Kwhores/trolls arrived.
Re:Since its only a build issue... by Bostik · 2002-08-01 01:44 · Score: 3, Informative

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.

--
There is no such thing as good luck. There is only misfortune and its occasional absence.
Re:Since its only a build issue... by kyjello · 2002-08-01 02:57 · Score: 1

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

--
kyjello is too damn smooth to make a signature.
Re:Since its only a build issue... by valdis · 2002-08-01 03:51 · Score: 2

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... by peter · 2002-08-01 05:40 · Score: 2

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

--
#define X(x,y) x##y
Peter Cordes ; e-mail: X(peter@cordes , .ca)
Re:Since its only a build issue... by Bostik · 2002-08-01 16:52 · Score: 2

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?

--
There is no such thing as good luck. There is only misfortune and its occasional absence.

I'm suprised... by DJPenguin · 2002-08-01 00:19 · Score: 2, Insightful

...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... by rozza · 2002-08-01 00:24 · Score: 1

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

--
Rohan Mitchell http://realityundef.sf.net -Reality Undefined
Re:I'm suprised... by Queuetue · 2002-08-01 00:26 · Score: 4, Interesting

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... by tps12 · 2002-08-01 00:38 · Score: 1

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!

--

Karma: Good (despite my invention of the Karma: sig)
Re:I'm suprised... by sgtrock · 2002-08-01 00:50 · Score: 1

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... by Libor+Vanek · 2002-08-01 00:51 · Score: 1

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... by mrfiddlehead · 2002-08-01 00:53 · Score: 1

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.

--
:wq
Re:I'm suprised... by Ded+Bob · 2002-08-01 00:57 · Score: 2

... 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... by alsta · 2002-08-01 00:58 · Score: 1

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

--
Wealth is the product of man's capacity to think. -Ayn Rand
Re:I'm suprised... by stinky+wizzleteats · 2002-08-01 01:08 · Score: 2

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... by bockman · 2002-08-01 01:18 · Score: 1

bitchX, also, as another poster pointed out.

--
Ciao
----
FB
Re:I'm suprised... by pmz · 2002-08-01 01:22 · Score: 1

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.

--
Healthcare article at Kuro5hin
Re:I'm suprised... by u-235-sentinel · 2002-08-01 01:39 · Score: 1

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?

--
Has Comcast disconnected your Internet account? Same here. You can read about it at http://comcastissue.blogspot.com
Re:I'm suprised... by ndecker · 2002-08-01 01:44 · Score: 1

To be exact, it is in Makefile.in and bf-test.c
Re:I'm suprised... by mpe · 2002-08-01 01:52 · Score: 2

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... by mpe · 2002-08-01 01:56 · Score: 2

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... by John+Hasler · 2002-08-01 02:51 · Score: 2

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.

--
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
Re:I'm suprised... by stinky+wizzleteats · 2002-08-01 03:01 · Score: 2

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... by supabeast! · 2002-08-01 03:19 · Score: 2

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

Surprised that the package was trojaned, or surprised that they actually admitted it?
Re:I'm suprised... by wurp · 2002-08-01 03:28 · Score: 2

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... by jazman_777 · 2002-08-01 03:41 · Score: 1

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.

--
Slashdot: Failed Car Analogies. Amateur Lawyering. Anecdote Battles.
Re:I'm suprised... by JimPooley · 2002-08-01 03:42 · Score: 2

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.

--

"Information wants to be paid"
Re:I'm suprised... by jazman_777 · 2002-08-01 03:44 · Score: 1

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!

--
Slashdot: Failed Car Analogies. Amateur Lawyering. Anecdote Battles.
Re:I'm suprised... by realdpk · 2002-08-01 03:54 · Score: 2

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... by Rob+Kaper · 2002-08-01 05:08 · Score: 2

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... by Rob+Kaper · 2002-08-01 05:13 · Score: 2

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... by mindriot · 2002-08-01 06:05 · Score: 2

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... by Rob+Kaper · 2002-08-01 06:13 · Score: 2

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... by Ateran · 2002-08-01 06:42 · Score: 1

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... by Rob+Kaper · 2002-08-01 06:53 · Score: 2

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... by prog-guru · 2002-08-01 06:57 · Score: 1

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

--
chris@xanadu:~$ whatis /.
/.: nothing appropriate.
Re:I'm suprised... by JustBrowsing · 2002-08-01 07:14 · Score: 1

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... by thomas.galvin · 2002-08-01 08:06 · Score: 1

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

--
Thomas Galvin
Re:I'm suprised... by Ded+Bob · 2002-08-01 08:35 · Score: 2

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... by frost22 · 2002-08-01 08:57 · Score: 2

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.

--
...and here I stand, with all my lore, poor fool, no wiser than before.
Re:I'm suprised... by Chexsum · 2002-08-01 12:53 · Score: 1

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.

--
Pixels keep you awake!

Security, Antisecurity and a Purposeless Anecdote by f00Dave · 2002-08-01 00:21 · Score: 4, Interesting

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?

--
.f00Dave

suggestion: changing the main ftp openbsd site by kipple · 2002-08-01 00:21 · Score: 2

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

--
-- There are two kind of sysadmins: Paranoids and Losers. (adapted from D. Bach)

Re:suggestion: changing the main ftp openbsd site by kipple · 2002-08-01 02:08 · Score: 2

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.

--
-- There are two kind of sysadmins: Paranoids and Losers. (adapted from D. Bach)

How many people do check the MD5 checksum? by frleong · 2002-08-01 00:21 · Score: 3, Insightful

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? by GigsVT · 2002-08-01 00:24 · Score: 5, Informative

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.

--
I've had enough abrasive sigs. Kittens are cute and fuzzy.
Re:How many people do check the MD5 checksum? by stevey · 2002-08-01 00:30 · Score: 4, Interesting

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? by zmooc · 2002-08-01 00:31 · Score: 3, Interesting

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?

--
0x or or snor perron?!
Re:How many people do check the MD5 checksum? by Queuetue · 2002-08-01 00:31 · Score: 1

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? by Lemuel · 2002-08-01 00:34 · Score: 1

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? by norwoodites · 2002-08-01 00:38 · Score: 2

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? by Quixote · 2002-08-01 00:45 · Score: 5, Interesting

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? by GigsVT · 2002-08-01 00:47 · Score: 2, Informative

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.

--
I've had enough abrasive sigs. Kittens are cute and fuzzy.
Re:How many people do check the MD5 checksum? by maxwell+demon · 2002-08-01 00:48 · Score: 2, Insightful

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

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

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

--
The Tao of math: The numbers you can count are not the real numbers.
Re:How many people do check the MD5 checksum? by Mr_Silver · 2002-08-01 00:55 · Score: 3, Insightful

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.

--
Avantslash - View Slashdot cleanly on your mobile phone.
Re:How many people do check the MD5 checksum? by Ded+Bob · 2002-08-01 01:00 · Score: 2

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? by Anonymous Coward · 2002-08-01 01:02 · Score: 1, Informative

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? by ckd · 2002-08-01 01:18 · Score: 3, Funny

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? by (startx) · 2002-08-01 01:23 · Score: 5, Informative

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? by Hater's+Leaving,+The · 2002-08-01 01:39 · Score: 1

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

--
Keeping /. cynic density high since the fscking Kwhores/trolls arrived.
Re:How many people do check the MD5 checksum? by Junta · 2002-08-01 01:41 · Score: 2

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

--
XML is like violence. If it doesn't solve the problem, use more.
Re:How many people do check the MD5 checksum? by (startx) · 2002-08-01 02:18 · Score: 2

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? by AraQniD · 2002-08-01 02:21 · Score: 1

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

--
-- i will protect you from ideals to save you from defeat
Re:How many people do check the MD5 checksum? by (startx) · 2002-08-01 02:23 · Score: 2

thing even. damn I need to start hitting preview.
Re:How many people do check the MD5 checksum? by pmz · 2002-08-01 02:26 · Score: 2

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.

--
Healthcare article at Kuro5hin
Re:How many people do check the MD5 checksum? by stevey · 2002-08-01 02:30 · Score: 1

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? by pmz · 2002-08-01 02:31 · Score: 2

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.

--
Healthcare article at Kuro5hin
Re:How many people do check the MD5 checksum? by pmz · 2002-08-01 02:39 · Score: 2

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.

--
Healthcare article at Kuro5hin
Re:How many people do check the MD5 checksum? by Geekboy(Wizard) · 2002-08-01 03:11 · Score: 2

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? by Flower · 2002-08-01 03:35 · Score: 2

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?

--
I don't want knowledge. I want certainty. - Law, David Bowie
Re:How many people do check the MD5 checksum? by msimm · 2002-08-01 03:47 · Score: 1

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

--
Quack, quack.
Re:How many people do check the MD5 checksum? by realdpk · 2002-08-01 04:16 · Score: 2

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? by realdpk · 2002-08-01 04:27 · Score: 2

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? by Rob+Kaper · 2002-08-01 05:06 · Score: 2

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? by kasperd · 2002-08-01 05:19 · Score: 1

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.

--

Do you care about the security of your wireless mouse?
Re:How many people do check the MD5 checksum? by peter · 2002-08-01 05:22 · Score: 2

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.

--
#define X(x,y) x##y
Peter Cordes ; e-mail: X(peter@cordes , .ca)
Re:How many people do check the MD5 checksum? by prog-guru · 2002-08-01 06:32 · Score: 1

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.

--
chris@xanadu:~$ whatis /.
/.: nothing appropriate.
Re:How many people do check the MD5 checksum? by Tom · 2002-08-01 07:06 · Score: 2

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.

--
Assorted stuff I do sometimes: Lemuria.org
Re:How many people do check the MD5 checksum? by repoleved · 2002-08-01 07:55 · Score: 1

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? by prog-guru · 2002-08-01 08:34 · Score: 1

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.

--
chris@xanadu:~$ whatis /.
/.: nothing appropriate.
Re:How many people do check the MD5 checksum? by thomas.galvin · 2002-08-01 08:36 · Score: 1

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.

--
Thomas Galvin
Re:How many people do check the MD5 checksum? by Ded+Bob · 2002-08-01 08:37 · Score: 1

You are just begging for a fork in the back. :)
Re:How many people do check the MD5 checksum? by repoleved · 2002-08-01 13:11 · Score: 1

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? by Tony-A · 2002-08-01 21:43 · Score: 2

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? by Tony-A · 2002-08-01 23:35 · Score: 2

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

Checksum...? by DJPenguin · 2002-08-01 00:22 · Score: 5, Interesting

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...? by Roofus · 2002-08-01 00:26 · Score: 1

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...? by lertl · 2002-08-01 00:51 · Score: 3, Informative

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...? by swdunlop · 2002-08-01 01:26 · Score: 1

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.

--
Weapons of Mass Analysis
Re:Checksum...? by crawling_chaos · 2002-08-01 01:28 · Score: 2

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.

--
You can only drink 30 or 40 glasses of beer a day, no matter how rich you are.
-- Colonel Adolphus Busch

This is another victory for Open Source!!! by Anonymous Coward · 2002-08-01 00:22 · Score: 1, Funny

Isn't it?

Re:This is another victory for Open Source!!! by TandyMasterControl · 2002-08-01 05:14 · Score: 2

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.

--
Johnny Quest has two Daddies.

Idle curiosity by Glytch · 2002-08-01 00:22 · Score: 3, Informative

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 by reeve · 2002-08-01 00:46 · Score: 4, Informative

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.

--
Reeve the cat
Re:Idle curiosity by GCU+Friendly+Fire · 2002-08-01 02:42 · Score: 2, Informative

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 by GCU+Friendly+Fire · 2002-08-01 03:45 · Score: 3, Informative
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 by Cupis · 2002-08-01 07:55 · Score: 1
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 by GigsVT · 2002-08-01 00:22 · Score: 5, Interesting

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?

--
I've had enough abrasive sigs. Kittens are cute and fuzzy.

Re:Trojan by Anonymous Coward · 2002-08-01 00:39 · Score: 1, Insightful

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 by GigsVT · 2002-08-01 01:07 · Score: 1

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.

--
I've had enough abrasive sigs. Kittens are cute and fuzzy.
Re:Trojan by JamesKPolk · 2002-08-01 03:33 · Score: 2, Informative

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.

It wasn't orgianally like that. by Neon+Spiral+Injector · 2002-08-01 00:23 · Score: 5, Informative

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. by Fluffy+the+Cat · 2002-08-01 00:27 · Score: 5, Informative

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. by Sibeling · 2002-08-01 00:47 · Score: 1

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

--
-- Sib
Re:It wasn't orgianally like that. by ahaning · 2002-08-01 00:53 · Score: 1

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

--
Withdrawal before climax is very ineffective and those who try this are usually called "parents."

Trojan executes code read via /bin/sh by XTaran · 2002-08-01 00:25 · Score: 3, Informative

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?

--
-- There is no place like $HOME.

Re: Trojan executes code read via /bin/sh by XTaran · 2002-08-01 01:54 · Score: 1

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.

--
-- There is no place like $HOME.
Re: Trojan executes code read via /bin/sh by XTaran · 2002-08-01 07:12 · Score: 1

No, it has been removed already.

SCNR.

--
-- There is no place like $HOME.

Trojaned source distributions by dzym · 2002-08-01 00:26 · Score: 5, Interesting

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 by Anonymous Coward · 2002-08-01 01:32 · Score: 1, Interesting

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 by dzym · 2002-08-01 01:51 · Score: 1

Erm, that reply was a bit more paranoid than I was hoping for.
Re:Trojaned source distributions by mborland · 2002-08-01 03:41 · Score: 2

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 by ScottKin · 2002-08-03 13:48 · Score: 1

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

Can you say "paranoid"?

--
I don't give a rat's behind about "karma" here or anywhere else. Don't like what I have to say here? Deal with it!

How to stop this happening again? by uchian · 2002-08-01 00:26 · Score: 1

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? by ndecker · 2002-08-01 00:44 · Score: 1
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? by tburkhol · 2002-08-01 00:48 · Score: 2, Insightful

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? by bockman · 2002-08-01 01:12 · Score: 1
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.
--
Ciao
----
FB
Re:How to stop this happening again? by Hanashi · 2002-08-01 01:33 · Score: 2, Interesting

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

--
Check out my eclectic infosec blog at InfoSecPotpou
Re:How to stop this happening again? by LinuxHam · 2002-08-01 02:05 · Score: 2

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.

--
Intelligent Life on Earth

OpenSSH by Anonymous Coward · 2002-08-01 00:28 · Score: 5, Informative

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 by mce · 2002-08-01 02:13 · Score: 1

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

--
Linux user since early January 1992.
Re:OpenSSH by orkysoft · 2002-08-01 03:58 · Score: 1

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

--

I suffer from attention surplus disorder.
Re:OpenSSH by mce · 2002-08-01 04:41 · Score: 1

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.

--
Linux user since early January 1992.
Re:OpenSSH by Reziac · 2002-08-01 05:05 · Score: 2

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

--
~REZ~ #43301. Who'd fake being me anyway?
Re:OpenSSH by kasperd · 2002-08-01 05:34 · Score: 1

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.

--

Do you care about the security of your wireless mouse?
Re:OpenSSH by kasperd · 2002-08-01 05:37 · Score: 1

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.

--

Do you care about the security of your wireless mouse?
Re:OpenSSH by samrolken · 2002-08-01 06:25 · Score: 1

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

--
samrolken
Re:OpenSSH by Fred+Ferrigno · 2002-08-01 07:30 · Score: 1

The trojan could be easily modified to connect over port 80, and what firewall is going to block that?
Re:OpenSSH by Bert64 · 2002-08-01 09:53 · Score: 1

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.

--
http://spamdecoy.net - free throwaway anonymous email - avoid spam!

looks like it's from our australian friends by Anonymous Coward · 2002-08-01 00:28 · Score: 1, Interesting

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 by dzym · 2002-08-01 00:33 · Score: 2

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 by GigsVT · 2002-08-01 00:54 · Score: 1

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.

--
I've had enough abrasive sigs. Kittens are cute and fuzzy.
Re:looks like it's from our australian friends by jquirke · 2002-08-01 02:00 · Score: 2

FreeBSD != OpenBSD

--jquirke
Re:looks like it's from our australian friends by jquirke · 2002-08-01 02:06 · Score: 2

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 by jquirke · 2002-08-01 02:10 · Score: 1, Offtopic

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

Mod my post down please.
Re:looks like it's from our australian friends by ViVeLaMe · 2002-08-01 05:19 · Score: 1

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.

--
i had a sig, once..
Re:looks like it's from our australian friends by GigsVT · 2002-08-01 06:47 · Score: 1

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?

--
I've had enough abrasive sigs. Kittens are cute and fuzzy.

Re:Irony by JyB · 2002-08-01 00:28 · Score: 1

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

--
Wow. And what's that big red button for ?

Re:Irony by yatest5 · 2002-08-01 00:31 · Score: 1

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

--

Mod parent up! [a] by Anonymous Coward (Score:5) Thurs, June 31, @13:37

Re:what's up with OpenBSD? by JyB · 2002-08-01 00:31 · Score: 1

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

--
Wow. And what's that big red button for ?

What's the big worry by back@slash · 2002-08-01 00:32 · Score: 5, Funny

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.

--
This comment was generated by a Squadron of Ultra Ninjas

Re:What's the big worry by kludge99 · 2002-08-01 02:28 · Score: 2, Funny

either does that C:\> prompt

Healthy versions still available..? by virve · 2002-08-01 00:35 · Score: 2, Informative

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

Dit it make into any distro? by bockman · 2002-08-01 00:36 · Score: 1

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.

--
Ciao

----

FB

My analysis by lertl · 2002-08-01 00:40 · Score: 4, Informative

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.

Slashdotted (copy of the weblog) by MavEtJu · 2002-08-01 00:43 · Score: 5, Informative

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.

--
bash$ :(){ :|:&};:

Re:Slashdotted (copy of the weblog) by smnolde · 2002-08-01 01:49 · Score: 2

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) by Proquar · 2002-08-01 13:36 · Score: 1

Mavvie, You rule!

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

--
---- *dog sitting next to a computer, with his beady eyes shifting left to right*
Re:Slashdotted (copy of the weblog) by Proquar · 2002-08-01 16:30 · Score: 1

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.

--
---- *dog sitting next to a computer, with his beady eyes shifting left to right*
Re:Slashdotted (copy of the weblog) by tallackn · 2002-08-01 16:34 · Score: 1

You go girl!!!
Re:Slashdotted (copy of the weblog) by Eggplant62 · 2002-08-01 22:47 · Score: 2

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... by Bush_man10 · 2002-08-01 00:46 · Score: 1

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

--
"I believe in everything in moderation. Including moderation." -Dean DeLeo, Stone Temple Pilots

Re:Gentoo... by ndecker · 2002-08-01 00:54 · Score: 3, Informative

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... by Spider[DAC] · 2002-08-01 01:56 · Score: 1

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.

--
I didn't do this, now did I?

Re:OpenBSD is holy! by lertl · 2002-08-01 00:47 · Score: 1

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

Well, I guess that's what they get... by MrBadbar · 2002-08-01 00:48 · Score: 3, Funny

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

Re:Well, I guess that's what they get... by pmz · 2002-08-01 02:47 · Score: 2

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.

--
Healthcare article at Kuro5hin
Re:Well, I guess that's what they get... by dohcvtec · 2002-08-01 03:09 · Score: 1

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?

--
-- Never hit a man with glasses. Hit him with a baseball bat.
Re:Well, I guess that's what they get... by pmz · 2002-08-01 03:17 · Score: 1

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.

--
Healthcare article at Kuro5hin
Re:Well, I guess that's what they get... by strombrg · 2002-08-01 03:40 · Score: 1

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

Re:what's up with OpenBSD? by Militant · 2002-08-01 00:49 · Score: 1

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

--
"The future comes 60 minutes an hour no matter who you are or what you do." The Screwtape Letters - C.S. Lewis

Re:what's up with OpenBSD? by Mercaptan · 2002-08-01 00:49 · Score: 2, Interesting

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.

--
-- "Sucks to your ass-mar"

New catch phrase by martinde · 2002-08-01 00:50 · Score: 4, Funny

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 by LizardKing · 2002-08-01 01:24 · Score: 2, Informative

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 by dohcvtec · 2002-08-01 01:42 · Score: 1

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

--
-- Never hit a man with glasses. Hit him with a baseball bat.
Re:New catch phrase by dohcvtec · 2002-08-01 02:58 · Score: 1

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

--
-- Never hit a man with glasses. Hit him with a baseball bat.
Re:New catch phrase by iabervon · 2002-08-01 03:03 · Score: 2

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 by mat.h · 2002-08-01 05:12 · Score: 1

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 by bockman · 2002-08-01 07:02 · Score: 1

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

--
Ciao
----
FB
Re:New catch phrase by Syberghost · 2002-08-01 07:51 · Score: 2

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 by f00zbll · 2002-08-01 00:51 · Score: 2, Interesting

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 by JimPooley · 2002-08-01 03:48 · Score: 2

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

--

"Information wants to be paid"

Just a Thought to prevent this.. by Akor · 2002-08-01 00:51 · Score: 1

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.. by yatest5 · 2002-08-01 01:00 · Score: 5, Funny

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.
--
- Mod parent up! [a] by Anonymous Coward (Score:5) Thurs, June 31, @13:37
Re:Just a Thought to prevent this.. by Grax · 2002-08-01 03:51 · Score: 1

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.

--
Coding Blog
Re:Just a Thought to prevent this.. by Akor · 2002-08-01 06:40 · Score: 1

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.. by Skapare · 2002-08-01 08:57 · Score: 2

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.

--
now we need to go OSS in diesel cars
Re:Just a Thought to prevent this.. by yatest5 · 2002-08-01 19:33 · Score: 1

Sorry man, it was an easy +5 karma target, and I need it to wind up people on here :)
--
- Mod parent up! [a] by Anonymous Coward (Score:5) Thurs, June 31, @13:37

Re:Quality control and open source by c13v3rm0nk3y · 2002-08-01 00:56 · Score: 1

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.

--
-- clvrmnky

Re:Another reason.. by SealBeater · 2002-08-01 00:59 · Score: 2

to subscribe to Bugtraq

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

SealBeater

--
-- Its survival of the fittest...and we got the fucking guns!!!

Re:j00 R 0wn3d lol by Anonymous Coward · 2002-08-01 01:01 · Score: 2, Funny

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.

How was that possible by ndecker · 2002-08-01 01:11 · Score: 1

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.

Why not hack the md5 checksums? by Anonymous Coward · 2002-08-01 01:13 · Score: 2, Insightful

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? by disappear · 2002-08-01 01:39 · Score: 3, Interesting

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? by slamb · 2002-08-01 03:21 · Score: 2

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? by glwtta · 2002-08-01 04:54 · Score: 2

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

--
sic transit gloria mundi

Open Source PKI Needed? by carbon60 · 2002-08-01 01:15 · Score: 4, Interesting

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

--

--
Adam Sherman
Freelance Geek

Re:Open Source PKI Needed? by carbon60 · 2002-08-01 01:51 · Score: 1

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

--

--
Adam Sherman
Freelance Geek
Re:Open Source PKI Needed? by hyperstation · 2002-08-01 02:29 · Score: 1, Flamebait

you could dump debian and use gentoo
Re:Open Source PKI Needed? by fizbin · 2002-08-01 03:06 · Score: 3, Insightful

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? by groen · 2002-08-01 04:08 · Score: 1

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? by hyperstation · 2002-08-01 04:57 · Score: 1

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? by cras · 2002-08-01 05:44 · Score: 1

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? by fizbin · 2002-08-01 06:49 · Score: 2

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.

GnuPG a good idea by giminy · 2002-08-01 01:18 · Score: 2, Insightful

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.

--
The Right Reverend K. Reid Wightman,

Re:GnuPG a good idea by Gemini · 2002-08-01 02:20 · Score: 1

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 by Abcd1234 · 2002-08-01 04:06 · Score: 4, Informative

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 by OttoM · 2002-08-01 19:58 · Score: 1

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:what's up with OpenBSD? by duffbeer703 · 2002-08-01 01:22 · Score: 2

OpenSSH is a subproject of the OpenBSD project.

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

--
Conformity is the jailer of freedom and enemy of growth. -JFK

Re:Why aren't people asking as to whom is doing th by dfn5 · 2002-08-01 01:23 · Score: 2

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

--
-- Thou hast strayed far from the path of the Avatar.

DON'T DO THAT !!! by Salsaman · 2002-08-01 01:28 · Score: 2

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 !!! by back@slash · 2002-08-01 02:21 · Score: 1

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.

--
This comment was generated by a Squadron of Ultra Ninjas

hostinfo by suwain_2 · 2002-08-01 01:29 · Score: 2, Interesting

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

--
________________________________________________
suwain_2 :: quality slashdot p

Re:hostinfo by mindriot · 2002-08-01 06:24 · Score: 2

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.

Portscan of the backdoor IP by CajunArson · 2002-08-01 01:37 · Score: 2, Interesting

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.

--
AntiFA: An abbreviation for Anti First Amendment.

Not the fault of OpenBSD? by Anonymous Coward · 2002-08-01 01:37 · Score: 1, Insightful

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? by lertl · 2002-08-01 01:55 · Score: 1

I just wanted to prevent the upcoming "OpenBSD? Har har har, secure as Cheddar Cheese or what?" flamewars.
Re:Not the fault of OpenBSD? by Tuzanor · 2002-08-01 02:35 · Score: 4, Informative

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? by dadragon · 2002-08-01 05:53 · Score: 1

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

--
God save our Queen, and Heaven bless The Maple Leaf Forever!

Re:Another reason.. by Branc0 · 2002-08-01 01:40 · Score: 1

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?

--

rm -rf /home/leia

Ummm, not quite. by jotaeleemeese · 2002-08-01 01:48 · Score: 2

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

--
IANAL but write like a drunk one.

Prescient Alan Cox / Theo exchange by wfrp01 · 2002-08-01 01:49 · Score: 5, Interesting

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

--

--Lawrence Lessig for Congress!

Re:Prescient Alan Cox / Theo exchange by wfrp01 · 2002-08-01 01:58 · Score: 2

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

--

--Lawrence Lessig for Congress!
Re:Prescient Alan Cox / Theo exchange by wfrp01 · 2002-08-01 02:44 · Score: 2

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.

--

--Lawrence Lessig for Congress!
Re:Prescient Alan Cox / Theo exchange by Florian+Weimer · 2002-08-01 03:50 · Score: 2

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 by wfrp01 · 2002-08-01 04:14 · Score: 1

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.

--

--Lawrence Lessig for Congress!

for more information by shivan · 2002-08-01 01:54 · Score: 1

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

Re:what's up with OpenBSD? by grub · 2002-08-01 01:57 · Score: 2

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

--
Trolling is a art,

Re:Quality control and open source by jasonrfink · 2002-08-01 01:58 · Score: 1

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

DUH! by 4of12 · 2002-08-01 01:59 · Score: 2

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.

--
"Provided by the management for your protection."

Re:DUH! by Tony-A · 2002-08-02 16:30 · Score: 2

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.

Re:suspicious! person who reported KNEW ip owner by palfreman · 2002-08-01 02:02 · Score: 1

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.

Could Freenet, GnuNET help here? by grumbel · 2002-08-01 02:03 · Score: 2, Interesting

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.

Great! by Rogerborg · 2002-08-01 02:06 · Score: 2

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?

--
If you were blocking sigs, you wouldn't have to read this.

Re:Why aren't people asking as to whom is doing th by saintlupus · 2002-08-01 02:11 · Score: 1

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... by bass_miologics · 2002-08-01 02:18 · Score: 1

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... by kaisyain · 2002-08-01 03:01 · Score: 1

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... by Charlotte · 2002-08-01 03:10 · Score: 1

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.

Is this a good excuse ? by unixmaster · 2002-08-01 02:21 · Score: 1

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

--
Never learn by your mistakes, if you do you may never dare to try again

Re:Is this a good excuse ? by unixmaster · 2002-08-01 02:25 · Score: 1

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

--
Never learn by your mistakes, if you do you may never dare to try again

no, what we really need by bass_miologics · 2002-08-01 02:23 · Score: 1

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 by gimpboy · 2002-08-01 04:59 · Score: 1

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

--
-- john
Re:no, what we really need by gimpboy · 2002-08-01 11:25 · Score: 1

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

--
-- john

Re:This is why I don't use open-source programs... by hyperstation · 2002-08-01 02:26 · Score: 1

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.

I think it's okay now by hardave · 2002-08-01 02:27 · Score: 5, Interesting

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 by Clue4All · 2002-08-01 05:56 · Score: 1

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

--

Is your browser retarded?

What else is modified? by Stephen+Samuel · 2002-08-01 02:36 · Score: 2

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?

--
Free Software: Like love, it grows best when given away.

Re:What else is modified? by Abcd1234 · 2002-08-01 04:09 · Score: 2

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? by SN74S181 · 2002-08-01 06:02 · Score: 2, Insightful

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? by T-Punkt · 2002-08-01 09:08 · Score: 1

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 by bee · 2002-08-01 02:36 · Score: 3, Insightful

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.

--
At least mafia-owned pizzarias make excellent pizza. Compare to Bill Gates.

Re:How to fix this from the site it's calling by Clue4All · 2002-08-01 06:27 · Score: 1

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.

--

Is your browser retarded?
Re:How to fix this from the site it's calling by bee · 2002-08-01 07:53 · Score: 2

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.

--
At least mafia-owned pizzarias make excellent pizza. Compare to Bill Gates.

FYI: Gentoo OK by jehreg · 2002-08-01 02:42 · Score: 3, Interesting

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 by questionlp · 2002-08-01 03:11 · Score: 1

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 by glwtta · 2002-08-01 05:12 · Score: 2

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?

--
sic transit gloria mundi
Re:FYI: Gentoo OK by doomy · 2002-08-01 14:39 · Score: 1

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.

--
...free your source and the rest would follow...

I know who DID IT! by evrim · 2002-08-01 02:49 · Score: 1

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.

--
Evrim ULU sysadm http://www.core.gen.tr

Re:I know who DID IT! by Anonymous Coward · 2002-08-01 04:16 · Score: 2, Funny

Archer Daniels Midland?

I thought that they just trojaned congress...

blocking network traffic by mborland · 2002-08-01 02:55 · Score: 3, Informative

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 by strombrg · 2002-08-01 03:32 · Score: 1

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 by Abcd1234 · 2002-08-01 03:59 · Score: 2

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 by mborland · 2002-08-01 05:42 · Score: 2

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 by DeputySpade · 2002-08-01 07:54 · Score: 1

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.

--

This space intentionally left blank

Re:This is why I don't use open-source programs... by jonabbey · 2002-08-01 03:02 · Score: 2

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

--
- jon

Ganymede, a GPL'ed metadirectory for UNIX

Does this during the "make"? by StupidKatz · 2002-08-01 03:11 · Score: 1

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"? by greenrd · 2002-08-01 06:36 · Score: 2

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.

--
Female Prison Rape in NY
Re:Does this during the "make"? by 1729 · 2002-08-01 09:16 · Score: 2, Insightful

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"? by Chexsum · 2002-08-01 11:33 · Score: 1

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

--
Pixels keep you awake!

theo by pmf · 2002-08-01 03:17 · Score: 1

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

Wiped the machine too early? by _bug_ · 2002-08-01 03:19 · Score: 1

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?

Interesting by bythescruff · 2002-08-01 03:27 · Score: 1, Interesting

"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

>

--
Chuck Norris: Socialism == a thousand years of darkness.

Re:Interesting by Accelerated+Joe · 2002-08-01 05:25 · Score: 2

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.

--
They who would give up an essential liberty for temporary security, deserve neither liberty or security

Seems like OpenSSH 3.4 trojaned too by unixmaster · 2002-08-01 03:34 · Score: 2, Interesting

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

--
Never learn by your mistakes, if you do you may never dare to try again

Re:what's up with OpenBSD? by timeOday · 2002-08-01 03:36 · Score: 1

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.

Rebuilding from source, and paranoia by valdis · 2002-08-01 03:37 · Score: 3, Informative

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... by realdpk · 2002-08-01 03:38 · Score: 2

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

Re:what's up with OpenBSD? by grub · 2002-08-01 03:55 · Score: 1

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

--
Trolling is a art,

public key authentication by gimpboy · 2002-08-01 03:59 · Score: 2, Insightful

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.

--
-- john

Re:This indicative of open-source development proj by f00Dave · 2002-08-01 04:00 · Score: 1

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.

--
.f00Dave

too many assumptions.. by gimpboy · 2002-08-01 04:07 · Score: 2

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.

--
-- john

Re:too many assumptions.. by gimpboy · 2002-08-01 06:25 · Score: 1

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.

--
-- john

Re:Why aren't people asking as to whom is doing th by arkane1234 · 2002-08-01 04:12 · Score: 1

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*

--
-- This space for lease, low setup fee, inquire within!

Trolling for karma, eh? by Inoshiro · 2002-08-01 04:12 · Score: 4, Insightful

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.

--
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.

Re:Trolling for karma, eh? by wfrp01 · 2002-08-01 05:11 · Score: 2

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?

--

--Lawrence Lessig for Congress!
Re:Trolling for karma, eh? by HiThere · 2002-08-01 09:44 · Score: 2

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.

--

I think we've pushed this "anyone can grow up to be president" thing too far.

Re:Telnet - because Theo is an asshole by arkane1234 · 2002-08-01 04:19 · Score: 1

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?

--
-- This space for lease, low setup fee, inquire within!

Where are the public keys? by Anonymous Coward · 2002-08-01 04:24 · Score: 2, Insightful

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? by TeddyR · 2002-08-01 04:43 · Score: 2

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

--

--
Time is on my side

Re: Debian signed packages by 183771 · 2002-08-01 04:37 · Score: 1

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 by SaDan · 2002-08-01 04:49 · Score: 1

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:j00 R 0wn3d lol by BitHive · 2002-08-01 04:53 · Score: 1

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... by vsprintf · 2002-08-01 05:30 · Score: 1

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... by John+Sullivan · 2002-08-02 00:52 · Score: 1

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

--
This is my World Wide Web of Whatever

Post-mortem? by flacco · 2002-08-01 05:40 · Score: 2

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?

--
pr0n - keeping monitor glass spotless since 1981.

Bad news and Good news by Sloppy · 2002-08-01 06:02 · Score: 2, Insightful

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.

--
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.

Re:Bad news and Good news by glwtta · 2002-08-01 07:26 · Score: 5, Informative

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.

--
sic transit gloria mundi
Re:Bad news and Good news by Sloppy · 2002-08-01 10:29 · Score: 1

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?

--
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Re:Bad news and Good news by glwtta · 2002-08-01 15:56 · Score: 2

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

--
sic transit gloria mundi

Gentoo is Good to Go by FreeUser · 2002-08-01 06:23 · Score: 2

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

--
The Future of Human Evolution: Autonomy

Re:Gentoo is Good to Go by glwtta · 2002-08-01 07:13 · Score: 3, Insightful

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.

--
sic transit gloria mundi

Re:This was not our fault by singollo · 2002-08-01 06:24 · Score: 1

-- 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:what's up with OpenBSD? by ImpTech · 2002-08-01 06:41 · Score: 1

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.

Re:203.62.158.32 (because) by Wouter+Van+Hemel · 2002-08-01 06:49 · Score: 1

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 by Dahan · 2002-08-01 06:50 · Score: 2

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 by lagoon · 2002-08-01 06:54 · Score: 1

Check out http://www.openssh.org/txt/trojan.adv

--
The world doesn't need you.

Re:How many people do check the MD5 checksum-wrong by Wouter+Van+Hemel · 2002-08-01 07:02 · Score: 1

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... by BalkanBoy · 2002-08-01 07:07 · Score: 1

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.

--
'A lie if repeated often enough, becomes the truth.' - Goebbels

#include <expletive.h> by ewhac · 2002-08-01 07:19 · Score: 2

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

--
Editor, A1-AAA AmeriCaptions

Re:This was not our fault by MrDoran · 2002-08-01 07:31 · Score: 1

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 by glwtta · 2002-08-01 07:33 · Score: 2

cute.

--
sic transit gloria mundi

Re:The original binary was replaced by SN74S181 · 2002-08-01 07:35 · Score: 1

Binary? Everybody here is talking about source code.

THIS IS NOT THEO by cperciva · 2002-08-01 07:44 · Score: 2

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.

--
Tarsnap: Online backups for the truly paranoid

List Of Servers by Myuu · 2002-08-01 08:44 · Score: 1

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)=
"

--

forget it.

Who changed the source code and how? by Bob+Loblaw · 2002-08-01 09:11 · Score: 1

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.

I've done things like that. by jc42 · 2002-08-01 10:00 · Score: 2

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

--
Those who do study history are doomed to stand helplessly by while everyone else repeats it.

Re:I've done things like that. by Chexsum · 2002-08-01 11:51 · Score: 1

Programmers who put backdoors in their programs are crackers!

--
Pixels keep you awake!
Re:I've done things like that. by jc42 · 2002-08-01 12:41 · Score: 2

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.

--
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
Re:I've done things like that. by Chexsum · 2002-08-02 18:31 · Score: 1

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

--
Pixels keep you awake!

History keeps repeating itself (new 0day exploit?) by kemikalzen · 2002-08-01 11:46 · Score: 1

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

--
Bodø community site

Safe SSH by Izanagi · 2002-08-01 11:55 · Score: 1

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.

--
SCO (noun.)- A Slimy Corporate Ogre. Often seeks free money.

The odds are just to high to be coincidence. by tallackn · 2002-08-01 15:02 · Score: 1

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

What about the Cygwin binary by GekkePrutser · 2002-08-01 15:04 · Score: 1

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 by herbierobinson · 2002-08-01 16:10 · Score: 2

It answer inverse DNS with "203.62.158.32".

--
An engineer who ran for Congress. http://herbrobinson.us

Re:Slashdot Effect by AjR · 2002-08-01 20:54 · Score: 1

WHo's the Larry Niven fan then?

--
...Upgrade now to Schrodingers Dog...

Yes and No by FreeUser · 2002-08-04 04:00 · Score: 2

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

--
The Future of Human Evolution: Autonomy

Re:Yes and No by glwtta · 2002-08-04 04:55 · Score: 2

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.

--
sic transit gloria mundi

Re:Another "OBSERVATION" by applejacks · 2002-08-04 13:06 · Score: 1

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:Telnet - because Theo is an asshole by arkane1234 · 2002-08-05 03:45 · Score: 1

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.

--
-- This space for lease, low setup fee, inquire within!

373 of 566 comments (clear)