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."
Whether the source is open or closed, you're going to have something slip through all those lines of code.
The key here is that it is caught and corrected, and solutions offered.
I am the evil aardvark!
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
...or does anyone else think that the way that this particular exploit was handled was, to say the least, irregular...
Personally, I'd go as far to say that I would rather switch to an alternative SSHd in the period that we were given from the presence of the exploit being announced to the fix being released - rather than following the "everyone upgrade now to our super-duper-improved privaledged seperated version"
It just seems to me that rather than attempting to help us users, the way that this bug was handled was just a huge PR stunt...
and I dont like it
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.
So if it is commented out, is it enabled, or disabled?
#ChallengeResponseAuthentication yes
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?
The OpenSSH guys are guilty of the worst kind of underhanded dealing in this matter. As a vendor, I'm frankly, disgusted in every sense of the word. They deliberately compromised the security of other vendors through their actions by:
* posting a workaround that broke functionality but didn't fix the problem,
* failing to disclose (in advance) a workaround that does close the hole,
* failing to release the source code to vendors before detailing the vulerability to the general public,
* deliberately releasing the vulnerability five days earlier than expected, catching vendors off-guard, and
* using strong-arm scare tactics to force a very broken feature on the end-user community.
In short, they have made a mockery of reasonable procedure for security updates.
If this is what we should expect from OpenSSH when future security vulnerabilities arise, then I, for one, will be investigating alternatives to OpenSSH, and I strongly encourage other vendors to do the same. The security of our users' systems is too precious to be left in the hands of someone who does not have their best interests in mind.
120 character sigs suck. Make it 250.
no it's not because he was afraid some black hat
could run diff.
it's because the vendors wouldn't cooperate to
make the privsep work and he got all frustrated
because the other code couldn't be fixed in time
either.
Hm. Man, as for me - Solaris failed to show its advances over linux. SunBlade 100 (you know, this entry-level Sun WS) with Solaris 8, compared with otherwise equal Intel box with linux - Solaris sucks
performance-wise, not counting desktop usability.
They've probably got finely tuned scheduler, working VM subsystem, and so on and so forth, but, in our development and usage Solaris is inferior to Linux.
Slackware is not affected by this security problem. You need BSD_AUTH, S/KEY, or PAM to have a potential problem
Pat, since you're reading this thread, I'd like to take the opportunity to issue a big THANK YOU for all your hard work, and for maintaining your uncommonly sensible attitude towards Slackware. Please, don't ever change.
With other OS distros, be it linux, other bsd's, commercial unix'x or stuff from MS, many services are turned on by default. Services provided by packages not necessaraly developed in house. The vendor hasent audited the code so is realy unaware of the risk of running it. The sysadmin is doubly unaware of the risk; he hasent audited the code (or is taking the word of a trusted auditor..) and may not be compleatly aware that the code is even running.
OpenBSD "secure by default" means that when a system is installed somebody has to make a concious decision to enable services, and thus make the system less secure (bug free services or not; think "airplane rule" here). Hopefully the person enabling the service will think about the security consiquences of doing so. If they dont thats not realy OpenBSDs fault.
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.
Agreed. I have been hardcore into Slackware since around 1997 and always keep coming back. Thank you for you rhard work, and keeping slackware the way it is, and the way linux should be.
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
Er... the .spec file is the part of the source RPM that details how the package is built.