Slashdot Mirror
OpenSSH Vulnerability Disclosed, Version 3.4 Released
Dan writes: "OpenSSH 3.4 has been released and will be shortly available on all mirrors. All versions of OpenSSH's sshd between 2.9.9 and 3.3 contain an input validation error that can result in an integer overflow and privilege escalation. OpenSSH 3.4 fixes this bug." And kylus writes: "The previously mentioned vulnerability in OpenSSH has been disclosed by ISS X-Force today on the BugTraq list. This is a potential remote root compromise, and while there is a workaround, it's advised that users upgrade to version 3.4 as soon as they can."
I'm impressed that the OpenSSH team gave us advance warning that this bug was going to be announced, and also how to reduce the risk (privilege separation).
From [openssh-unix-announce] Re: Upcoming OpenSSH vulnerability
It was suitably humble of them to admit it and update their homepage.
Unfortunately, one remote hole is all you need. Such is the Unix nature.
That would be pure speculation on your part.
1. Tell you lot nothing, get the fix done and released (in which case you wouldn't have known about it until the fix came out).
2. Or tell you there is a bug, you can fix it temporarily by doing this until we get the fix out. In which case you decide either to follow him or do nothing (because after all, thats what you'd have been doing if nothing was said)
3. Or say, we have a bug, it's this and this and this is how you exploit it and then you lot all either scramble to install something else or sit around praying you don't get rooted whilst they compose a fix because now everyone and their dog know exactly how to exploit it.
Geeesh, be thankful he actually told you number 1. Next time, I think he should probably stick with number 2 and just tell you when the fix is out - at least then you can't whinge about it.
Avantslash - View Slashdot cleanly on your mobile phone.
Assuming this is true for all RH7.3 boxen, there aren't hundreds of boxes waiting to be r00ted. It sounds from the comments like Debian is vulnerable - what about older RedHats, and other distros?
I get the feeling this was is a molehill made into a mountain.
DWR is Ajax for Java
the openbsd website has been updated:
One remote hole in the default install, in nearly 6 years!
*sigh*
Fun while it lasted, I guess...
The Daily Build
This is simply not true. I believe that security is important, and that there are certain measures sysadmins should take in order to keep undesirables out of their systems. But every time somebody finds some tiny little problem in a program, suddenly the world screeches to a halt, everyone panics, and we get bombarded with headlines and emails demanding that we upgrade immediately or our data centers will explode. Oh, and by the way, don't forget to put two pages of credits on the exploit's "whitepaper".
The result of all this horn-tooting is that I don't care anymore. Whenever someone utters the words "security advisory" I simply stop listening, because 99% of advisories are crap.
irb(main):001:0>
the vendors would no longer have the head start they needed
Except the vendors didn't get a head start because the vulnerability wasn't disclosed to them either. They were just handed OpenSSH 3.3 and told, "Here. Use this. It doesn't fix the hole that we won't tell you about, but it will prevent it from being exploited." Now, today, the vendors have finally been allowed to see a patch and can start implementing fixes other than "upgrade to the newest version".
Hmm... "There's a problem, we won't tell you what it is, but if you upgrade to the newest version, it will go away, plus you'll get nifty new features along with it!" Where have I heard that before?
Every choice in handling this matter carries a different consequence for different groups of people. Theo can't serve every group equally.
As it turns out, recent OpenBSD installations were exposed to this, where many other platforms were not exposed.
The first question Theo had to decide was whether to spread the information around before his own user community was protected. Of course every vendor thinks they are entitled to this information. No black hats here! No rooted systems here! Your secrets are safe with us. Tell enough vendors, your secret is certain to escape.
The next question to decide is whether to create a window of opportunity for his own user base to protect themselves before giving away anything of use to the black hat community.
He can't do this without admitting that there is a big problem here. But any further details he gives become clues for those who might try to discover the flaw themselves.
As it stood, he had an option to put forward which allowed his user base to protect themselves while giving nothing away to his black hat adversaries. privsep is a case of Doing The Right Thing. I'm sure Theo does get frustrated that vendors don't put a higher priority on Do The Right Thing initiatives.
On OpenBSD itself, privsep has been there quite a while and I don't think it would be considered untested in its nascient environment.
He couldn't very well suggest to his user base "disable challenge/response". That's like backing away from Mike Tyson.
What could he have done differently?
He could have informed his own user base to install the reasonably well tested privsep version *in advance* of informing other vendors of the actual problem in secrecy *after* he completed the actual bug fix patch. This would have meant keeping the patch secret for another week or two.
But instead he chose to put his boot up the ass of vendors who think that compatibility with PAM is more important than adopting a model which eliminates 90% of the future prospect for more of the same.
If Theo were entirely sane he wouldn't be doing what he's doing. Maybe he has your best interests at heart, but the same best interests you chose for yourself.
There are always people who have good reasons for delaying The Right Thing. In the long term, I think these people contribute more to the sorry state of security that brash actions by people like Theo.
If you invest your faith in Doing The Right Thing on the technical merits, I think you'll stick with OpenSSH. If you prefer the relationship model of working hand in hand behind the scenes, maybe you won't.
The difference here is:
1) The problem was fixed in a couple of days
2) The upgrade was free
3) This is the first serious security hole OpenBSD has had in nearly 6 years.
For extra credit, compute the following: average number of days between disclosure and fix, times the cost of the upgrade that gives it to you, times the number of remote-root-level security exploits in your average BorgOS over 6 years.
At least mafia-owned pizzarias make excellent pizza. Compare to Bill Gates.
Actually, I know what's wrong. Theo's notice was basically "There's a hole, wait until we release a new version and then do a major version upgrade in a hurry.". ISS's notice was "Here's the hole, here's the way to close it in your existing software.". I'd rather Theo have told everybody the simple way to close the hole right off, rather than leaving everyone hanging.
Wow, that's a shitty way to make a conclusion. You're assuming everything in Red Hat is properly documented... Try looking at the source RPM instead...
SIG: HUP