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
Does anyone know why it was kept so hush? It's so unlike the open source community to not just put it all right out there.
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
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
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.
Well at least they are honest about it, and are trying to fix it. There's a company out here in redmond that could take lessons in honesty and security from them.
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?
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! $-)
I wonder is Apple is going to release a minor OSX update for this. If they do, they prove themselves worthy supporters of OpenSource and creators of an OS that truly respects security.
If they don't, welll, they're still a 100 times more secure than 95% of the market
When will I end this grieving ? When will my future begin ?
Gobble! Gobble!
Strange women lying in ponds distributing swords is no basis for a system of government.
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.
Where are vendor statements that usually accompany such announcements?
Thankfully the default setup on SuSE 7.3 is "ChallengeResponseAuthentication no". Unfortunately, the default on Redhat 7.[0123] is "ChallengeResponseAuthentication yes".
"Naaah, OSS has no security holes."
According to my sshd configuration under Mandrake 8.0, this is already set to "n". In fact, the comment above the line makes things even more clear:
# Comment to enable s/key passwords or PAM interactive authentication
# NB. Neither of these are compiled in by default. Please read the
# notes in the sshd(8) manpage before enabling this on a PAM system.
ChallengeResponseAuthentication no
Once more unto the breach, dear friends, once more, Or close the wall up with our American dead!
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
[mithras:~] mithras% ssh -V
OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
and
cat
# Uncomment to disable s/key passwords
#ChallengeResponseAuthentication no
so it seems plausible that we're vulnerable, though I'm not sure.
However, this note indicates that 3.3p1 (and presumable now 3.4) compiles fine, including the privilege-separation option, without problems.
While Apple expects to have shipped 5 million computers with Mac OS X (and OpenSSH) by the end of the year, SSH is turned off by default. So this and future problems should affect only those who know what the hell SSH is...four nine eighteen twenty-7 thirty-nine forty-7 fiftyeight sixty-nine seventy-9 eighty-8 one-hundred-and-nine one-twenty
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.
In my /etc/ssh/sshd_config:
:)
# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
This was on my Red Hat Linux 7.1 workstation (also acts like a private server only to me). Do I assume this is at no value right now and I don't need to worry?
Thank you in advance.
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
Is there a page anywhere that summarizes the holes/bugs/exploits in OpenSSH discovered in the last, say, two years? year? six months?
- undoware.ca
The 3.3 release of OpenSSH required that with PrivilegeSeparation turned on, Compression had to be turned off for Linux kernels in the 2.2 line. Does anyone know if this is true for the 3.4 release as well, or has that been fixed?
Al Qaeda has ninjas!
I discovered after downloading and building 3.4p1 on my Solaris 7 box that Solaris doesn't support a shared memory feature 3.4's privilege separation uses. As a result, you can enable privilege separation or compression, but not both at the same time. Just something to be aware of if you're considering an upgrade. (It's possible more recent versions of Solaris don't have this problem.)
(See subject.)
I use stunnel and telnet (plus mandatory ssl certs - so even though telnetd might have a bug, you can't exploit it without a valid cert).
Years ago I took a look at ssh and thought it would have lots of problems (kludgy, lots of complex features stuffed into one binary). The "Sendmail" of remote admin.
The past years have vindicated my decision many times over.
Sure stunnel and openssl have had some problems too, but as long as the stunnel people don't try to stuff tons of features in, it'll still be much better than ssh securitywise.
You could try vnc over stunnel if you really need GUIs.
Cheerio,
Link.
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.
My SSH config on Red Hat 7.2 has exactly the same comment and setting you quoted, with challenge/response set to no. I can't remember now how I installed SSHD originally, though, i.e. whether I downloaded a newer version or used the one on the Red Hat CDs.
I'm going back to telnetd and blind optimism.
jack's bicycle is music to my ears
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.
There are lots of people who would prefer not to program in C or C++, but find that all the alternatives have drawbacks, including a lack of avilable enviroments for all platforms. Chip Salzenberg's comments on the language selection for the failed Topaz project are very interesting.
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 awaySo how long did it take you to find the bug? And why didn't you tell us about it?
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
...rather than rebuilding. Generating new RPMs for 6.2 is a total nightmare.
ftp.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
Can someone please explain why this vulnerability was handled this way? Why wasn't there a maintainance release that just fixed the @#$@#% problem?
On the other hand, I charge by the hour when I upgrade my client's machines. So thanks Theo! $-)
Why don't YOU make a fix and give it away? How about a whole OS? Oh, I see, so shut up.
DMCA, Hollings, Palladium. What might have sounded like paranoia is now common sense.
They did? Are you saying that someone physically came around to your house, put a gun to your head and forced you to upgrade?
If not (and I suspect not) then you weren't forced to do anything.
Avantslash - View Slashdot cleanly on your mobile phone.
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 worst part is that many who upgraded (Anyone using Debian Potato for instance) actually BECAME vulnerable to at least a non-root exploit by upgrading where the old 1.2.3 version they were using didn't have the hole at all.
While I understand that full disclosure before a fix is available can be a bad thing, leading people to break their systems AND become vulnerable to the exploit when a simple configuration change could have protected the vast majority of users is far worse.
I would think that full disclosure to maintainers is a MUST.