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."
locate the "ChallengeResponseAuthentication" line in /etc/ssh/sshd_config (typically) change to :
"ChallengeResponseAuthentication no" and restart sshd
http://www.codewolf.com - Just good stuff to waste time
Did any one of the many black hat groups out there actually work up a exploit or was this caught in time that it was just a possibility of being exploited?
Strange women lying in ponds distributing swords is no basis for a system of government.
"One remote hole in the default install, in nearly 6 years!" you can see it here: OpenBSD
~Shane
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
All that you need to do, as far aas I understand it, is turn Challenge/Response authentication off (which nobody uses anyway). So the line in /etc/ssh/sshd_config reads:
and then restart the daemon.
Big deal.
I don't see any need to upgrade anything. Yes, privilege separation is nice in terms of future security, but I prefer the (more likely) known stability of software that has been in use for a while.
Debian security policy is that vulnerability fixes are backported (to avoid adding anything that could cause instability or further insecurity); this was made impossible by Theo's and ISS' advisory which lacked any details about the exploit. This may have been justified had the exploit not be able to be prevented by a simple configuration change (in order to give administrators time to prepare an upgrade their systems), but not for this.
Cheers, Theo, you just cried Wolf for the entire community. If there ever is a hole major enough that everyone should (or might want to) upgrade to a version which is by nature immune rather than give away the exploit by releasing a patch, noboby's going to believe you now, and probably not anyone else either.
How does this authentication method work? I just disabled it, and I was still able to log in using my RSA keys and password authentication (which are the only methods I use). The documentation says it's for s/key authentication, but what is that? How common is this authentication method, and who would use it?
They were told to release an upgrade to a version that broke existing functionality, was largely untested, and were also told that it didn't directly fix the issue anyhow. The were told this without any details of what the vulnerability was, or even if it would affect them (and it turns out that nearly every distro will be unaffected).
I don't blame any distro for being a little wary and asking for more information. I believe Debian summed it up very well in their advisory.
Don't use SSH. Switch to telnet instead....
ChallengeResponse... oh please! Telnet's never had these problems.
(note for the humour impared: this is a *joke*).
--
Garett
Okay, busy morning but glancing at the news, here's what I see:
There was a bug in the challenge/response code between 3.0-3.2.3. In fact, it's an "overflow" according the advisory. This means to me, it should be a fairly easy fix. Quote:
In addition, this overflow only works when SKEY and/or BSD_AUTH is enabled. But this seems to be "not enabled...in many distributions". How about Linux? However, OpenBSD has BSD_AUTH enabled (natch). Quote:
And now to add insult to injury, the 3.3 I installed yesterday has a new different buffer overflow, so I have to jump to 3.4 now (does it have any new bugs too?)
I don't like to jump versions on production machines. I like to fix what's running for minimum disturbance.
Can someone please explain why this vulnerability was handled this way? Why wasn't there a maintainance release that just fixed the @#$@#% problem?
I know: since the bug affected so many people, Theo thought it would be better to bury the problem in his privsep code, instead of fixing it and letting the blackhats run "diff" and find it for an easy 0-day-'sploit. In other words, security by obscurity, just like the big guys. That stinks, if you ask me.
On the other hand, I charge by the hour when I upgrade my client's machines. So thanks Theo! $-)
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.
Although it looks like Theo could have simply told everyone to disable challenge/response authentication, I'll venture to guess that he had a reason for not doing so. Consider that his original announcement was deliberately obscure, in order to avoid advertising the vulnerability to crackers, while vendors scrambled to patch their systems. If Theo had originally said "turn off challenge/response", all the crackers would immediately know where to look for the vulnerability, and the vendors would no longer have the head start they needed.
Here it is a few days later, the vendors have been given time to implement fixes, and we have disclosure. What are you people complaining about? Apart from the lack of social grace that he's famous for, I'd say Theo handled this about as securely as he could. Moreover, he did so by folloing the procedure widely accepted in the security community. Am I missing something?
More simple is usually more secure.
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
CheckPasswords false
And then reboot your sshd.
Finally mail me, and I'll check that you really are safe. Oh and don't about slashdot users giving you bad advice you can be sure to only get accurate information here.
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
So, what do we know about who is affected? Immediately after reading the announcement, I checked Red Hat Linux's build of OpenSSH. The configure script positively reports that the affected authentication mechanisms are not available. 'ssh -v' does not indicate that challenge-response authentication methods are available either. I imagine that other Linux distros are similar?
RHL configure output:
OpenSSH has been configured with the following options:
...
Smartcard support: no
S/KEY support: no
BSD Auth support: no
How secure any software you're running on your system(s) depends on the quality of the code audit done on the code. I'm not judging the standard of the OpenSSH's team code audit here: things will slip through given the inherent complexity of software.
Privilege separation is a step in the right direction. By minimising the amount of code running as root, it makes code audits simpler and more through, and minimises the damage any potential exploit could do in the part running as a normal user.
Stepping back from the situation, privilege separation is just a bandaid for the lousy UNIX security model. Yes, granted, UNIX / Linux (i have no experience with other UNIX systems, so i shall reserve comment) have a security model that's used, as compared to Windows 9X. (Windows 2K has a security model, but the MS culture makes it difficult to administer it, but i digress). However, this security model is too coarse grained: it grants "root" too many privileges, too many rights. This is evident in the move towards ACLs, for example in NSA's SE Linux, as well as LIDS.
We need to overhaul the security model to one that's not prone to insecure software as much. Note I said as much:No system is 100% secure, and I don't want to replace my system with a toaster.
Appreciate feedback. Thanks. =)
Be kind. There are too many mean people out there already.
There were basically two ways to fix your configuration. One was simple, and actually the default on most systems. The other is a pain in the ass, but Theo likes the second method because it is aesthetically more pure; a better implementation of a security conscious application.
The distributions (who couldn't get any information about the nature of the bug, just the suggestion that they fix the pain in the ass way of using sshd) correctly figured that they were being railroaded and balked.
For what it is worth, privelege separation is a better architecture for a security concious program, but setting up a chroot jail and adding new users, along with the brokeness of several ports of the new privsep code especially in the area of pluggable authentication modules (ie: RedHat) means that although I now have 3.4p1 iunstalled on my boxen, I also have privsep turned off. Less pure, but I'm a pragmatist, not an idealist.
LibBT: BitTorrent for C - small - fast - clean (Now Versio
Generally, the defaults are displayed in the config file, as commented out instructions. In other words, the default is yes.
I can't wait until djb decides to write his own ssh. You can say what you want about djb and his personality, but he does know how to write some secure software. Sure, it's not the easiest thing to install and you have to create a boatload of users, but privilege separation has been in qmail since 1.0.0. Theo is getting around to it in v3.3? Never heard of any root compromises from qmail or djbdns. So hopefully this latest hole in OpenSSH has annoyed djb to the point of rolling his own.
if you don't need all the features of SSH, try telnet+SSL+certs
It's likely to be safer.
I've been using stunnel+telnet for years and I have had to patch/upgrade a lot fewer times than people using SSH.
Cheerio,
Link.
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.
Meaning this brouhaha, of course...
Just to combat some of the misinformation that has been spreading around here:
Don't complain too much folks... you could have to do without a robust free ssh implementation.
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.
Monday, June 24, 2002 11:22 PM
There is an upcoming OpenSSH vulnerability that we're working on with ISS.
Details will be published early next week.
....etc etc etc
Now ISS has up'd the ante and released it justa day and a half later. 1 and 1/2 days isn't a lot to verify that a production environment will not be adversely effected byANY new/changed element. So it would seem that "working with ISS on this issue"is synonymous"we are waiting to get blindsided". This also leads into another interesting issue. Why did ISS's reckless announcement take minutes to get through bugtraq and the OpenSSH's initial, responsible warning take 24+ hours to process? I can plainly see that Theo's letter was sent on Monday but for some reason only gets here today. I know that SMTP mail is slow..but I don't thinkmy server isTHAT slow. Fortunately, it showed up on the vuln-watch list as well and we were able to help spread the word.
> X-Force is aware of active exploit development forthis vulnerability.
I don't know if I really even believe you on this certainlyyour recent actions are not that of a company that seeks to garner trust. Of course the minute anyone suggests there is a problem with product XYZ, thousands of bored people are going to start poking around "actively" trying to develop an exploit! But blind testing from scratch would certainly have taken longer than the proposed "quiet week" before publishing details.So, lets suppose it was a more informed testing. So who knew enough about this to let it out? ISS and the OpenSSH dev team. One is made up of hard working developers who love aprogram enough give their time away to make a really great product. The other is composed of people who routinely socialize with the underground "active exploit development" community. In my opinion, at least one side would have absolutelyno motive leak their information. So I propose: A: Your analysis of the exploit development process was faulty B: there was no active development for an exploit, and you released the info for your own good.C. Someone's teamis leaking information.
In any event, there no need for any furtherunderground exploit "R&D"; everyone now has the diff blueprints to get directly to the end goal. Granted, there are people out there intelligent enough totake the time find the issue and to code an exploit without this knowledge. But these type of people wouldn't likely release it to the general populace, instead it would be used for select targets. Targets that would most likely already have security teams in placeand be up on warnings and patches. Instead we have a patch diffs in the hands of everybody and now lower skilled programmers can code the exploit. These people will spread the exploit far and wide simply for fame; only this time the targets will be everyone.
No one wins with this route you have chosen ISS. You and your X-force team used to be a respected group in my book. In the past they have provided valuable information to the security community and helped companies across the world to better secure themselves, but the handling of this and the Apache vulnerabilities are shining examples of how NOT to do things. So much for ISS being a "Trusted" center of knowledge. Trust and honor are coins you can only spend once.
Nelson Bunker, CISSP VP of Security Critical Watch The opinions expressed in this advisory and program are my own and not of any company. The big print giveth, the little print taketh awayftp.openssh.org is getting hammered right now... sigh.
my old sig used to be funny, but then slashcode ate it and now it's not funny anymore