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

Comments

Workaround here:

[codewolf]

locate the "ChallengeResponseAuthentication" line in /etc/ssh/sshd_config (typically) change to :
"ChallengeResponseAuthentication no" and restart sshd

Re:Workaround here:

[f00l]

So if it is commented out, is it enabled, or disabled?

#ChallengeResponseAuthentication yes

Re:Workaround here:

[Squeezer]

It will take whatever the default is that is programmed into the code, which is prolly yes. So in other words if its commented out its more then likely enabled. So uncomment it and change it to no.

I think I should start an OpenSSH remote root exploit of the month club.

Re:Workaround here:

[lunenburg]

That would indicate that the default is "yes", so if you want to disable it, you need to uncomment it and set ChallengeResponseAuthentication to "no". Then restart sshd.

Re:Workaround here:

[codewolf]

Actually, it is safe to make the ChallengeResponseAuthentication no change and restart, until you upgrade. But, you can not assume your version is vulnerable solely from the config file, it's a compile time option that makes it vulnerable, and this is different on many systems, so be safe, do the workaround until you upgrade.

Re:Workaround here:

[pauldy]

What about setting
PAMAuthenticationViaKbdInt no
as well. It appeared in the mailing list.

Re:Workaround here:

[Anonymous Coward]

Hey, Adam! How's post-IRC life treating you, you worthless little shit?

Re:Workaround here:

[Anonymous Coward]

I think you have the comment topic wrong, Squeezer. Don't you mean "Reach arounds here!!!" Gulp it down!

Re:Workaround here:

[killmenow]

How about this workaround:

RSAAuthentication yes
PubkeyAuthentication yes

Everything else NO

I have a bizcard CD with putty and a key on it. I take it with me. I can login wherever I want and even if the computer has a keylogger, who gives a rat's ass? Without the key on that CD, they're not getting in. I don't know why anybody would use anything else.

I swear, when I first read this, I immediately downloaded the new version but here's the rub: I don't have any compilers or development tools on my production boxes. You're an idiot if you do. So, to upgrade, I have to install gcc, make, etc., then recompile, then remove all that crap again. Thank God I turned off all that crap before now.

Now I can wait until there's a real need to go through those hassles.

Re:Workaround here:

[Anonymous Coward]

I have a bizcard CD with putty and a key on it. I take it with me. I can login wherever I want and even if the computer has a keylogger, who gives a rat's ass? Without the key on that CD, they're not getting in. I don't know why anybody would use anything else.

I would hope you still encrypt your key... Because otherwise a simple pickpocket could gain access to your accounts!

Of course, the passphrase could always be picked up by a keylogger, but without the key to decrypt, it wouldn't do much good..

Re:Workaround here:

[Anonymous Coward]

Liek its probably an intel box, and they can get the files there anyways, and if not they can cross compile, your not makign your box any more secure.

Re:Workaround here:

[MicroBerto]

I don't know, but I'm willing to bet that the number of times he's gotten laid certainly hasn't gone *DOWN* since he stopped IRCing so much...

Re:Workaround here:

[decaying]

[quote]
I don't have any compilers or development tools on my production boxes. You're an idiot if you do. So, to upgrade, I have to install gcc, make, etc., then recompile, then remove all that crap again.
[/quote]

Why not compile it on one of your non-production boxes, package it up and install onto production?

Re:Workaround here:

[poisonberry]

Nice. Is there a doc on setting this up somewhere or can you give the run down. Thanks

Re:Workaround here:

[killmenow]

Of course, I always put a passphrase on the key. In order to get in, you need the passphrase, the key, and the name of the account I login as.

While a pickpocket might wind up with the key, he is missing two other vital pieces of information needed to login.

And while a keylogger on an untrusted machine could get the login and passphrase, it is highly unlikely it will capture the key.

And if the key ever goes missing, it is trivial to make a new key.

Re:Workaround here:

[killmenow]

Like, it is x86, fersure. Dude, you are, like, soo smart! And, like, if my actions thwart 2/3rds of the 5cr1pt k1DD135 who haven't fuck's clue what to do if their d/l'ed tools don't work, then, like, i am, like, making my box, like, more secure, okay.

I make no pretenses that the steps I've mentioned are all that's necessary to stop determined crackers. But, contrary to what most 3l33t h4ck3r5 think, they are not l33t.

Imagine a pyramid diagram: About two-thirds of the way up horizontally there is a line. Beneath that line is centered text that reads "wannabes" or "k1dd135" representing the majority of the "hackers" out there who couldn't write their own shell code if they wanted to. About 1/8th from the top, there is another horizontal line, below which is the word "experienced, determined crackers" which represents people on whom the efforts I've mentioned will have much less effect. Above that line, is a single word: "Elite" which represents the few who you and I don't really know much about...and won't, because they are good enough not to let us know.

My efforts are enough to foil all of the bottom tier. They are enough that the middle tier are not interested, because what is to be gained by 0wn1ng my systems is negligible. Same goes for the top tier. What's here is not worth having. The task is to make it difficult enough so that script kiddies will realize: "there's nothing to see here...move along."

Re:Workaround here:

[Bert64]

What if the compromised machine (with keylogger installed) also duplicates the contents of the cd to a hidden file on the hd?

Re:Workaround here:

[killmenow]

Do you know of any tools that do this? The hard drive would fill up awfully fast if some background process were just copying contents of inserted CDs into a hidden (even compressed) file. As I said, it's not impossible for someone to get it, just highly unlikely.

Re:Workaround here:

[Bert64]

A simple script could be written to do that, the disk wouldn`t fill up too fast if the cds only contained an ssh key anyway.. and theres always the chance that an attacker will be interactively connected to the machine and manually start a copy of files.

Why was it kept hush hush?

[wub]

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.

Re:Why was it kept hush hush?

[zrodney]

it wasn't kept quiet for very long -- maybe a week
or two while solutions were implemented. The big
delay was that the vendors didn't believe it was
real.

Re:Why was it kept hush hush?

[YahoKa]

There wasn't a fix, and so it had to be kept hush :o

Re:Why was it kept hush hush?

[Tyrall]

Nope, the big delay wasn't vendors didn't believe 'it' was real, they had no clue what 'it' was.

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.

Re:Why was it kept hush hush?

[reelbk]

The details of the bug weren't disclosed immediately because there was no patch available. Now that it can be patched, most system will be protected from the script-kiddie storm. But, as usual, there are plenty of lazy and/or ignorant sysadmins who won't patch this.
It was hinted on bugtraq a while ago that a remote root exploit for SSH was discovered but would only be disclosed once patches were available.

Re:Why was it kept hush hush?

[mkldev]

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.

Re:Why was it kept hush hush?

[wackysootroom]

I could be that ISS does not want another PR fiasco like the one that it got when it released the Apache advisory recently

Re:Why was it kept hush hush?

[kevinank]

The rationale not exposing the exploit was that if the exploit became known then immediately there would be many thousands of machines that could be exploited. That would be bad, so the question became 'is there some way to disable the problem code without fixing the bug', then a bug fix can be delivered after without anyone getting hacked.

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.

Re:Why was it kept hush hush?

[Anonymous Coward]

You repackagers make me sick, all you do is gripe. THe folks at OpenSSH have worked their fucking asses off trying to make secure FREE code (in every sense of the word). They DID tell of a WORKABLE workaround until the patches were released. You gripe, you moan, you say you are going to look for another company that is willing to give a truely free implementation of SSH out.

Why the fuck dont you write your own? Because you are a goddamn repackager. You dont give anything out of any real value. Why dont you for once THANK the people who work so goddamn hard to help the community.

I am sick of you goddamn leeches. You leech leech leech, then cry because the blood is running low in your host. Parasites like yourself should either start contributing to projects like OpenSSH or shut the fuck up!

PS. Thanks to the folks at OpenBSD and OpenSSH for the many hours you have contributed to making the world a little more free and secure!

Re:Why was it kept hush hush?

[John Hasler]

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

The Debian security team just about killed themselves getting the upgrade out for all eleven architectures and patching and backporting it to Potato.

And now we find out that we were never vulnerable.
I think there will be a movement to put a price on Theo's head.

Re:Why was it kept hush hush?

[Anonymous Coward]

Mark this up. Ok the poster did use some harsh language. Ok he was a little upset. But listen to what he is pointing out. People here are biting the hand that feeds them. They are being fed free steak and cry they didn't get A1 with the steak.

However anyone feels about how the information was released. I think its clear that Theo wanted to make sure everyone was safe before the exploit was released. The man has done a lot for the community.

BTW mklinux is a piece of shit. I don't think the guy from mklinux has any grounds whatsoever to criticize.

Re:Why was it kept hush hush?

[datajack]

The last couple of weeks has demonstrated precisley what is wrong, from an end-user standpoint, with 'responsible disclosure' (yeuch!)

I don't know why, but ISS seemed to get under the skin of a lot of security researchers with their release of details of the recent Apache problem. This release was *directly responsible* for someone (I forget who, but thanks are due) to code a fairly simple work-around in the form of an Apache module, so that people can quickly install some protection whilst waiting for a fix to appear, and ancilliary apache addons (modssl, php etc.) to catch up with the new Apache release, so we are now maore-or-less protected whilst compiling, testing and installing new versiona of about half a dozen bits of software. Because of this release, the problem can be handled in a calm and non-disruptive manner.
Oh, and someone reported being hit with similar symptoms to this problem, well before ISS released the details.

Take that in contrast to when this OpenSSH problem hit the net. I was well aware of OpenSSH 3.3 and the new security features, and had a plan to wait till the next release (to check for implementation problems) and then upgrade all our servers in an orderly manner.
However,this morning, I opened Bugtraq to find a load of peeps that should know better (i.e. OpenSSH developers) screaming that there was a major root-exploit in the code I was currently running, that I had to upgrade immidiately, and no, they won't tell me what the problem is. Based on the available information, I made a judgement call, and suspended all incoming ssh access at the firewall until I could upgrade. As you can imagine, this pissed off a lot of customers. I also had to then reschedule my day to get, test and install this new version of SSH - I did not have time to put it through our usual QA process - to get us operational again.

To add insult to injury, when the details were released, it turns out to be a problem with a feature we do not even use and a simple config change was a suitable work-around.

Who do I get to bill for our (useless) 3 hour downtime?

Re:Why was it kept hush hush?

[kevinank]

And now we find out that we were never vulnerable. I think there will be a movement to put a price on Theo's head.

Before getting too upset with Theo, you should at least consider that security is Theo's life blood. The way he sees it, the primary bug in earlier versions of OpenSSH was the security architecture; by fixing that bug Debian is far ahead of the crowd since you will be impervious to a whole class of programming errors, of which this particular error is only a specific example.

He certainly didn't believe he was giving bad advice, and the fact that this whole thing has backfired on him will probably be setback enough. I'd certainly hate to see him burned so badly that he decides to drop out, just educated that even rational, well educated people don't always come to the same conclusions given the same data, and that he must let others come to their conclusions on their own.

For what it is worth I do admire the work the Debian team has done to get the new release integrated. I think it speaks volumes that the open team is also the only Linux distribution to have integrated the new features before the patch was released.

Re:Why was it kept hush hush?

[epine]

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.

Re:Why was it kept hush hush?

[mkldev]

I love it when someone calls me a leech....

I currently have kernel patches in the kernels of three shipping operating systems, and have helped in the development of kernel code for two others.

I manage three open source code development projects, two of which involve kernel development (the third is an X11 app).

I'm an active contributor to seven, count them, 7, open source projects, and there are others that I've simply gotten too busy to continue contributing to.

With the help of a team of about two other people I maintain one of only two working distributions of Linux on the PowerMac, not because I want to make money from it (I haven't made one single penny from MkLinux EVER), but because it helps others and helps me keep my systems running as well.

No, I haven't made any useful patches to OpenSSH. It's one of about a thousand packages that we have to maintain. For a team of 2-3 people working in their spare time to supporting several THOUSAND users for free, there's only so much you can do. :-)

In short, if using a piece of software makes me a leech, then so be it. I'm a leech, and proud of it, as is nearly everyone else reading this thread. Last I checked, the purpose of an open source project was to help the end user, and treating vendors with contempt in a way that hurts their users is not socially acceptable behavior.

Now admittedly, MkLinux is in the minority here, being one of only a handful of such projects that are both free and contribute code changes back upstream periodically.

I fully agree with you that companies that make money off distributions should contribute time and effort to making these projects work. Those of us who are already giving our blood, sweat, and tears and getting nothing from it other than the thanks of our user base, however, cannot possibly be expected to do that, and to suggest otherwise is, quite frankly, ludicrous beyond belief.

Now, I wrote with legitimate complaints about poor security practices. I'd very much appreciate it if you'd stick to the topic at hand. While you're at it, you might actually read something about what someone does before accusing them of being a leech and a repackager.

Re:Why was it kept hush hush?

[xmutex]

Because Theo de Raadt is a brat (ha! rhymes!) and anyone who says differently is a dirty liar or a micreant.

Re:Why was it kept hush hush?

[Anonymous Coward]

Whoopdie doo! You contributed a couple patches. To bad linux is not in need of patches, but a whole redesign. I am glad someone with your skills is on the job.

Re:Why was it kept hush hush?

[pdqlamb]

Re: "a version that broke existing functionality." FWIW, I was worried whtn Theo threw out his gentle hints (or was that a stinkbomb?) yesterday and tried to upgrade my systems to openssh 3.3. Fortunately, I tested it on one system before broadly deploying it. 3.3 was broke. Neither ssh nor sshd would interoperate with anything else. 3.4 seems to be working, with some (relatively minor) nits.

But after seeing the easy patch (ChallengeResponseAuthentication no in the sshd_config file and restart sshd), I wonder where I can contribute to the "get Theo's attention" fund.

Re:Why was it kept hush hush?

[kevin lyda]

huh?

the moment that the openssh team stands up and says to set challengeresponse to no, everyone knows what the bug is. yes, everyone has a chance to be secure, but it increases the chances that an exploit could exist while people are upgrading (remember, a fair portion of the world was asleep when the announcement went out).

and why all this abuse of theo? it was iss that released the details a week early with less then a day's notice.

Re:Why was it kept hush hush?

[Anonymous Coward]

You are using free software. Bill yourself, cheapskate.

Re:Why was it kept hush hush?

[John Hasler]

"the moment that the openssh team stands up and says to set challengeresponse to no, everyone knows what the bug is."

All had to do was tell us that pre-3.0 versions weren't vulnerable.

"it was iss that released the details a week early with less then a day's notice."

It was Theo who sent out a notice telling us we had _four_ _hours_ to package 3.3 while neglecting to mention that our stable distribution was not vulnerable.

Re:Why was it kept hush hush?

[Anonymous Coward]

How did this go from +2 to 0 flamebait. I personally can not see this as flamebait. I guess anon cowards opininions are somehow lesser than regular users.

Re:Why was it kept hush hush?

[rodgerd]

Which rather substantiates Alan Cos's scepticism...

Re:Why was it kept hush hush?

[mkldev]

I agree with many of your points. I've always regarded PAM as a necessary evil (very evil).

I disagree, though, that the real workaround couldn't be made available. The more vague the information, the more likely fascist network admins are to block port 22 entirely. Being able to lose partial functionality is better than losing all functionality, but only if that loss of functionality actually solves the problem. Some companies and individuals would be unable to turn that feature off, which is unfortunate, but at least they would know up-front what they were dealing with and could make an informed decision about how to react.

I applaud OpenSSH for pushing people to use privilege separation. That's a very good feature, and I'm glad to see that people are actually working on making it work correctly. It's an important security feature.

A word of caution, though. Privsep will reduce the risk of a root attack, but not by 90%. Unprivilleged logins can still do an awful lot of damage if a system admin hasn't kept up with fixes for local root exploits. Sad, isn't it? :-)

However, there -is- a right way to do a security update of a piece of software that minimizes the odds of anyone's computer being compromised. It goes something like this:

1. Fix your own copy, make binary-only release available on your distribution.
2. Security announcement to vendors through whatever channel. Include patch.
3. Vendors build and release binary updates. Announce these updates. Keep source private, including vendor-modified versions.
4. At a scheduled date, official source release. Vendors concurrently release modified source.

Ideally, there should be about a week from the initial patch to the source release. This gives vendors a chance to react, while still providing security to OpenBSD users. It also ensures that end-users' systems are protected to the maximum extent possible as soon as possible while minimizing the changes of black hats getting information on the hack.

An alternate variation on this involves releasing the source and binaries at once, so that the particularly cautious could build their own. The point being that it takes vendors time to build and qualify something as complex as SSH, and expecting it to just happen instantly is not a reasonable expectation, even for a large vendor with large resources.

The whole bit about vendors leaking information to black hats is disconcerting. If there's cause to believe that this is occurring, then better steps need to be taken to qualify vendors for this sort of information rather than simply exluding vendors from the information. If there are infrastructure needs in this area, I'd be happy to help in any way I can (time permitting, of course. :-)

Re:Why was it kept hush hush?

[cygnusx]

I have a question: Today OpenSSH was upped to 3.3p1 in stable because the team did not know what the problem was. Is there a chance that the Debian security team will decide that it's worth it to `go back' to the older version of OpenSSH which potato was using (which wasn't vulnerable), in keeping with the tradition of no-new-features in stable?

Re:Why was it kept hush hush?

[kevin lyda]

er, no.

openssh 2.9 was vulnerable too. a revised statement came out that says that openssh back to 2.3 is vulnerable.

Re:Why was it kept hush hush?

[Anonymous Coward]

Ummm, maybe Theo liked the "second method" because, unlike the first, it does not reveal anything about the vulnerability. If he had said that you could fix it be turning off challenge/response then everyone would know that that was where the bug was and would have a good chance of finding it.

OpenBSD

[Anonymous Coward]

At least OpenBSD.org updated their web page.

Re:OpenBSD

[return 42]

Score:0, Redundant

Whoops, my bad. Should've checked :)

Re:Post predictions

[stevey]

• Three person making post predictions

Open "Secure" Shell.

[rmadmin]

As far as my servers.. 'DOH!'.

I got a customer at a bank that almost went to another webhosting provider because we ran linux, and he wanted something more 'Practicle'. His suggestion, Solaris. Well.. Whats that.. Sol9 shipped with OpenSSH? I see.. much more secure than our pathetic linux servers! Putz.

Its not the cost of the software, its how you admin it.

Re:Open "Secure" Shell.

[Anonymous Coward]

Don't forget a finely tuned scheduler, proper memory management, and a _WORKING_ VM subsystem. No one uses Linux for real work, get over it.

Re:Open "Secure" Shell.

[BattleCat]

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.

Was there ever a working 'sploit?

[toupsie]

I have read much about this problem in OpenSSH and fearing the worst...checking logs to see how often my SSH version was scanned. However, as far as I know, I haven't had any break ins using a SSH exploit. Thank God for TCP Wrappers, at least that helps when you find out about these things.

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?

Re:Was there ever a working 'sploit?

[graboy]

"X-Force is aware of active exploit development for this vulnerability."
from http://online.securityfocus.com/archive/1/278818/2 002-06-23/2002-06-29/0

Looks like some patches are being merged into the source so now the bad guys will know where to look:
"make sure # of response matches # of queries, fixes int overflow; from ISS"

Re:Was there ever a working 'sploit?

[Bodhidharma]

"X-Force is aware of active exploit development for this vulnerability."

Translation: X-Force is currently developing an exploit for this vulnerability. Look for it soon on a skr1pt k1dd33 site near you.

That's twice now that X-Force jumped the gun and announced exploits early. I know this was an open secret among the open SSH community but they are forcing the maintainers to rush security fixes out prematurely.

Re:Was there ever a working 'sploit?

[evilviper]

I have it on good authority from a collegue of mine (okay, fine, he's a script kiddie, but he keeps up on all the '0day' exploits, so he comes in hanndy) that not only is there an exploit for OpenSSH, but there is one for the latest version of SSH.com's ssh server (3.2.0 IIRC).

He's a rather reliable source. In fact, he let me know that Apache on essentially ANY platform was vulnerable, long before IIS or Bugtrack had that info. Interestingly enough, a few days later, one of our servers (not one that I admin-I NEVER run Apache as Root) was Root'ed. It was just a small workgroup server, no real harm done.

Re:Was there ever a working 'sploit?

[Liedra]

Theoretically, though, you'd need to have an active exploit in order to discover the vulnerability? I mean, to go to your boss and say, "Hey, look here" sort of thing. Once proof of concept has been displayed, then get into the code and mechanism for it *shrug*

I say kudos to Mark Dowd for his months of work on this, and next time I come round, Mark, bottle of vodka for inducing mass hysteria! ;-)

- Liedra

New Slogan!

[skinney]

"One remote hole in the default install, in nearly 6 years!" you can see it here: OpenBSD

~Shane

Re:New Slogan!

[AndrewHowe]

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.

Re:New Slogan!

[Oztun]

No actually one exploit is all you need and so far no one seems to have it.

Re:New Slogan!

[AndrewHowe]

That would be pure speculation on your part.

Re:New Slogan!

[bbh]

Yeah, it was probably the guy with the exploit that updated the webpage :P

bbh

Re:New Slogan!

[rikkus-x]

The slogan meant nothing anyway. The only reason there were no holes in the default install was that there were virtually no network services running. My toaster is secure on the same principle.

Rik

Re:New Slogan!

[Anonymous Coward]

Not if it already has a patch. I would assume that any admin concerned about security will patch this as soon as possible.

"Such is the Unix nature."

No, such is the technology nature. Screw OS bickering, if don't make security a priority, you might as well put your admin/root password on your business card and hand it out at DefCon.

Re:New Slogan!

[Anonymous Coward]

You only think your toaster is secure.

Re:New Slogan!

[spunkykuma]

If I recall correctly, openbsd's default install often has some of the inetd services running, but there's not much useful from it (daytime, discard, date, etc.).

Re:New Slogan!

[bmetzler]

Unfortunately, one remote hole is all you need. Such is the Unix nature.

Isn't one remote hole all Windows needs too? Or isn't that the Windows nature?

-Brent

Re:New Slogan!

[zulux]

Isn't one remote hole all Windows needs too? Or isn't that the Windows nature?

The biggest security hole in Windows is the power-button. Turn it on, and POW! HACKED BY CHIN33SE!

Re:New Slogan!

[Rogerborg]

And that is the difference between open source and proprietary. You can argue until the cows come home which one is better, but open source is demonstrably more honest. If there's a hole, you find out about it. It isn't hushed up and smushed into the next Service Pack, regardless of whether it's being sploited or not.

I'm currently building a firewall machine for my brother. I'd considered openBSD, but was going to just stick to what I know and use a cut down Linux distro. But this changes my mind. I'm still old fashioned enough to respect honesty and integrity; people who display those virtues (I've found) tend to write better code, because they're more open to positive criticism and apply higher standards to their work. So openBSD it is, and roll on the next vulnerability, sometime in 2008.

Re:New Slogan!

[epine]

Safe ground there guy, staking out the non falsifiable position when the other side of the coin IS falsifiable (by example).

I'll believe someone had the exploit ahead of the fix when someone declares a compromised system.

Until then, all we have to go on is paranoia, and find that a thin gruel.

Re:New Slogan!

[T-Ranger]

True, but your "secure by default" is important to the OpenBSD people. There goal is to create a secure opearating system, period.

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.

Re:New Slogan!

[Wakko Warner]

Unfortunately, one remote hole is all you need.

Sort of like cock pushups.

Except the rooting is of a different nature.

- A.P.

Re:New Slogan!

[cachapa]

It's better than the alternative:
"5 hours without remote holes in the default install"

Re:New Slogan!

[Anonymous Coward]

Wait until you're a victim of the new "Distributed Denial of Breakfast" attack I've been working on, you won't be so smug then...

Re:New Slogan!

[Neon Spiral Injector]

And that is how all operating systems should be.

As another poster said above, the biggest hole in Windows is the power button. The default install of what ever Microsoft is calling the server addition of Windows 2000, has IIS running. If you just connect to the Internet to get your Windows Update you'll probally be exploited before it is done.

I know I put Apache on a machine that had never been a webserver before. I started right away testing the server side includes. When they didn't work I checked the error log. I was suprised to see that an IIS worm had attempted to exploit my machine before I even began testing.

I wish more Linux installs would ship with all listening services disabled. Make you turn on what you need, not turn off what you don't.

Re:New Slogan!

[pauldy]

Why not do what normal people do and bring up machines offline first in a staging area then configure and bring them online when you have the machine setup and configured properly. It is the way most professionals do it anyway. I would have to shoot someone on my team if they installed a sever and brought it online directly in the dmz.

Re:New Slogan!

[RustyTaco]

Actually, that sounds like fun! I might just have to do that this year. Oh course I won't have any useful data on the system and will probably have a "hardened" kernel with root neutered.

Yeah, I LOVE that idea!

- RustyTaco

...see you at DefCon.

Re:New Slogan!

[Neon Spiral Injector]

Don't get me wrong, that is what I do. Actually I build custom Linux installs from embeded to clustered servers. I only install what is needed.

But what I'm saying is, for the less than professional people out there, installs should be much tighter from the initial boot.

And I know there must be enough of these less-than-professional people out there, from the rate at which my new born machine started seeing IIS worm requests.

Re:New Slogan!

[Anonymous Coward]

This is really sort of like when you're watching your uptime get up there to 364 days and suddenly your power goes out for a few seconds, your machine reboots, and the next time you check you see " 17:30:25 up 5:24, 4 users, load average: 0.20, 0.15, 0.17". Then you go "DAMNIT!!!!!"

Re:New Slogan!

[carlfish]

Or, as JWZ put it: "___0___ days without an on-site injury!" (sic)

(although I had to un-caps it to get past the lameness filter)

Re:New Slogan!

[AndrewHowe]

You are assuming that anyone with an exploit would be jumping up and down, waving their dick in the air, shouting, "Me! Me! I have an exploit". Well, maybe they do, and meybe they don't. And maybe their dick is too small to see from where you are sitting...

Re:New Slogan!

[AndrewHowe]

Hmm. Well, everything in Windows is controlled by ACLs. Erm, well apparently in the distant past that was not true... But we can forget about that! Now this is something that is anticipated for inclusion into the Linux kernel, for example. 2.5? Who knows?
Anyway. The interesting thing is that the whole problem in the this OpenBSD case was to do with this "mitigation" feature. That is to say, that to mitigate the problems associated with a hack against the OpenSSH system, not all r00t facilities should have been available. Unfortunately, erm, well the exploit would get around that. So, you get this situation in which a single r00t hole (and here you see the difference between 0 and 1 [dontcha love binary?]) gives you carte blanche to do whatever the fuck your black evil heart desires.
Now, you might say to me, well, no fucker actually uses ACLs properly in Windows.
And you would probably be right.
Sigh.

Re:New Slogan!

[pauldy]

This is a sad and true fact. I just don't think the solution is for all services to come turned off when you install them. For me at least the logic is that if I install it I want to use it. This isn't an option with many of the IIS servers you see polluting the net right now.

Re:New Slogan!

[Anonymous Coward]

whatever.

he stole that from the joke in the window of the little custom sign shop next door to his club.

Re:Post predictions

[Anonymous Coward]

Don't forget: 50 people predicting posts like the lamers that they are.

Argh...

[Cutriss]

What you submitted appears below. If there is a mistake...well, you should have used the 'Preview' button!

Re:Argh...

[Anonymous Coward]

Okay. I'd like to know how the FUCK I can be trolling when I'm posting a reply to MY OWN GODDAMNED THREAD!

There's security leaks everywhere

[Black Aardvark House]

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'm impressed

[bigberk]

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

"There is an upcoming OpenSSH vulnerability that we're working on with ISS. Details will be published early next week.

However, I can say that when OpenSSH's sshd(8) is running with priv seperation, the bug cannot be exploited.
. . .
We've given most vendors since Friday last week until Thursday to get privsep working well for you so that when the announcement comes out next week their customers are immunized. That is nearly a full week (but they have already wasted a weekend and a Monday). Really I think this is the best we can hope to do (this thing will eventually leak, at which point the details will be published)."

Re:I'm impressed

[SmartyPants]

Yeah.. ISS Learnt from their F-Up on the apache hole they pre-announced a week ago.

Re:I'm impressed

[Anonymous Coward]

It is interesting to note that the type of hole found in OpenSSH is known among software professionals as an "asshole". This particular "asshole" has been named in honor of its discoverer, Theo the Rat. Analysts contend that despite extensive QA efforts the Theo asshole will be around causing software problems for the foreseeable future.

That was fast.

[newdaemon]

I just finished upgrading to 3.3.1 on my Slackware box with privsep enabled. I heard that 3.4 wouldn't be out until next week Monday. Does anyone know if compression in sshd will work on GNU/Linux with 3.4?

Is it just me....

[GnomeKing]

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

Re:Is it just me....

[cca93014]

Jeeezus, if you dont like it or the way the promote it dont use it. It's not like you are paying them.

How can you have a PR stunt for something as essential as SSH? It's like having a PR stunt for food.

Re:Is it just me....

[rosie_bhjp]

I'm not sure why people think this was handled badly.
OpenSSH enjoys a broad user base and is on a lot of trusted systems, a lot of admins trust their jobs to it. Theo, Neils, Markus et al. have been pushing for people to upgrade to the later versions that contain support for Privilege Separation which make this hole pretty much worthless in the first place. However, as Theo stated on the Announce list people have been hesitant to upgrade to the newer version.
ISS notified the OpenBSD/OpenSSH group of the security hole and just like every other exploit they find, they worked WITH the developers to give them a little time to develop/test the patch before they made the announcement. How is this different than anyone else?
Theo also said OpenSSH and the exploit wouldn't be released until next Monday, but the fix has been released today. My guess is that they agreed to do the announcement as soon as the patch was developed or Monday, whichever was sooner. The patch was completed/tested ahead of schedule, so there you go.
Congrats to ISS for discovering the flaw, they killed the five year streak.
Congrats to the OpenBSD team for putting together such a good system and hopefully the next streak will be even longer.

Now the hole has been disclosed, the patch has been released. Get off your arse and start patching or don't bitch when you get rooted.

Re:Is it just me....

[Jeremiah Blatz]

Not a PR stunt for SSH, a PR stunt for ISS. First the apache thing, and now this. Hell, there's even a plug in the advisory for their auditing software. Well, there's the cost of the increasing market penetration of Unix variants. The predatory, FUD-filled tactics of MS, virus protection makers, etc. are beginning to filter into our "perfect" little world.

Re:Is it just me....

[bellings]

and just like every other exploit they find, they worked WITH the developers to give them a little time to develop/test the patch before they made the announcement.

Are you implying that you know something about the Apache hole that hasn't made it onto the BugTraq shit-fling fest? I'm anxious to know!

Re:Is it just me....

[Geekboy(Wizard)]

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

Everybody, all chickens sold under the Tyson brand have been found to have been infected with athrax. Please DO NOT HANDLE THEM!!!

Is that a PR stunt?

Re:Is it just me....

[essdodson]

Its very suspicious that Theo suddenly urged everyone to upgrade to 3.3. The version 2.9 distributed with FreeBSD was not vulnerable, but after pushing everyone to upgrade to 3.3 it was. I think it was a trick to get other systems to a state to where it would be easy to show that there were many others who had the same problem. Lame.

Re:Is it just me....

[tzanger]

...or does anyone else think that the way that this particular exploit was handled was, to say the least, irregular...

I agree totally. What is that dude Theo smoking? We've had remote root exploits before and they were handled properly. This one was like a forced push for untested brand new privsep code. No thanks. I just added "ChallengeRepsonseAuthentication no" in my config instead.

To me it seemed like a PR stunt. Why it was handled this way I don't know, but I'm not going to jump when he demands everyone upgrade or else.

I'd go as far as to say I want to see a working exploit for this. It sounds fishy. An integer overflow (not a string overflow) causing remote root? I find that very hard to believe.

Pay no attention to the man behind the curtain...

Re:Is it just me....

[Crispy Critters]

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

You have found the big hole in the "window of opportunity" description of the danger of a bug (Bruce Schneier, Cryptograms and books). Fortunately, it gives even further support to the "full disclosure" movement.

We don't need to wait for the bug-fix release to secure our systems. We can switch to alternate products, change config files, and even turn off convenient services that are not strictly necessary or block them at the firewall temporarily.

Schneier says the window is open between discovery of the bug and the time when a fix is released (and longer until everyone fixes their systems). This is a perfect example of how full disclosure allows you to close the window even before a patch is developed.

Re:Is it just me....

[Anonymous Coward]

"Theo also said OpenSSH and the exploit wouldn't be released until next Monday, but the fix has been released today. My guess is that they agreed to do the announcement as soon as the patch was
developed or Monday, whichever was sooner. The patch was completed/tested ahead of schedule, so
there you go."

You're guess is wrong. Theo has stated that the first version of the fix took about 3 minutes to do and that it was fully tested a little bit after that. This was on the freebsd-security list.

Re:Is it just me....

[Znork]

The reason people think this was handled badly is because most people arent affected. As far as I can tell, pretty much everyone who isnt running xBSD hasnt been affected, and a workaround by changing one line in the config is _far_ easier than upgrading to a sortof broken version, followed by yet another upgrade to a less broken version.

Re:Is it just me....

[Anonymous Coward]

Check out gobbles' apache exploit.

Simple string stack smashes are becoming rarer (at least in commonly used open source apps). More complicated exploits (like integer wrap exploits and the BSD ftpd _ONE BYTE_ exploit) are far more common now.

Re:Is it just me....

[Anonymous Coward]

No.

Try this:

"Everybody, all chickens sold today are capable of killing your whole family instantly. We won't tell you how though. But if you switch to turkey (warning; turkey is not a working substitute for chicken at the moment) the effects of this problem are mitigated."

Then later it turns out that only the brand of chicken sold by the person putting out the advisory is affected, and turkey substitute is only semi-functional and actually introduces another exploitable bug.

Re:Is it just me....

[Anonymous Coward]

The announcement also included a way to protect yourself, ie. use privsep. So, the only one leaving a window open was your OS vendor by not having a working privsep implementation.

Re:Is it just me....

[Anonymous Coward]

No, what's lame is disregarding the second announcement that stated versions back to 2.3.1 are vulnerable also.

Cheers, Theo

[gorf]

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:

ChallengeResponseAuthentication no

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.

Re:Cheers, Theo

[BJH]

Yeah, this kind of pisses me off, too.
I went through my servers and set up suitable hosts.deny settings for each of them so as to prevent access from any machines that I don't run, and all along all I needed to do was uncomment one bloody line.

Thanks, Theo. I appreciate your work on OpenSSH, but pulling stunts like this is not a good way to promote your software.

Re:Cheers, Theo

[Anonymous Coward]

If there ever is a hole major enough that everyone should (or might want to) upgrade

Browse at -1 sometime. You'll see quite a few goat security holes in need of an upgrade.

Re:Cheers, Theo

[BJH]

Hmmm, that's weird... disabling ChallengeResponseAuthentication causes OpenSSH to show the username and hostname when asking for the password, whereas before it only showed the "Password:" prompt.
(In other words, it now displays "USER@HOST.NAME's password:")

It's not really a problem, since (obviously) you need to know what user you're trying to log in as, but it would suggest that it goes through different code paths when the option's enabled compared with when it's disabled, even if you're using the same authentication type each time.

Re:Cheers, Theo

[Anonymous Coward]

I belive just doing " ChallengeResponseAuthentication no" will not protect every thing. You can have sshd uses PAM to do auth also. This is needed for some system that might be using One-Time Passwords for example, atleast on Debian. To uses Debian's package for the opie-server have or not having "ChallengeResponseAuthentication" set to "no" or "yes" doesn't do anything.

The package hands off to PAM to do the auth. Which currenly will not work correctly with UsePrivilegeSeparation yes.

PAMAuthenticationViaKbdInt yes

Plus you then change /etc/pam.d/ssh to uses pam_opie.so instead of pam_unix.so in two places. Systems using OpenSSH 3.3 or 3.4 that want to uses opie-server right now are left only with two choices. 1) Set "UsePrivilegeSeparation no" so they can still uses One-Time Passwords.

2) Set "UsePrivilegeSeparation yes" breaks One-Time Passwords but will protect.

Re:Cheers, Theo

[Anonymous Coward]

Are debian people normally whiners?

Re:Cheers, Theo

[RiC!N]

Word up.

The same thing you mention about Debian is being done in FreeBSD-stable. They too have started to get the OpenSSH-3.3/3.4 in the base ASAP. They were told (by Theo) to upgrade or turn sshd off altogether.

Getting the privsep feature into the base system's OpenSSH is a good thing surely, but certainly not a requirement to deal with this vulnerability. As a matter of fact, the OpenSSH-2.9 (with backported security patches) used in -stable now and distributed with 4.6-RELEASE turns out to be not vulnerable at all.

Re:Cheers, Theo

[Matts]

You're trusting the same organisation that told us that the Apache bug wasn't exploitable on x86 Linux (and we later found out it was), that this is a trustable workaround?

No thanks, I'll upgrade my servers and enable priviledge separation. We may or may not see exploits that get around turning off the ChallengeResponseAuthentication bugs, but I'm not taking that chance.

Re:Cheers, Theo

[transient]

This is a problem throughout most of the security community, and it's the reason I don't subscribe to bugtraq anymore. At the risk of starting a flamewar, my impression of people who are really into security as a group is that they have an over-inflated sense of their own importance. Every seminar I attend, every publication I read, and every security expert I speak to tells me the same thing: that hordes of hackers (and now terrorists, too) are out to melt my hard drives and make me lose $1 million a minute.

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.

Re:Cheers, Theo

[platypus]

You're trusting the same organisation that told us that the Apache bug wasn't exploitable on x86 Linux (and we later found out it was), that this is a trustable workaround?

Minor correction (only AFAIK, please correct me if I'm wrong):
ISS told us that the bug was not exploitable on any 32bit plattform, later we found out that this bug is exploitable on 32bit BSDs (free* and open* IIRC).
It's not exploitable on x86 linux.

Re:Cheers, Theo

[Triumph The Insult C]

you say:
You're trusting the same organisation that told us that the Apache bug wasn't exploitable on x86 Linux (and we later found out it was), that this is a trustable workaround?

and

No thanks, I'll upgrade my servers and enable priviledge separation. so you don't trust them for one thing, but another?

Re:Cheers, Theo

[gorf]

It's not exploitable on x86 linux.

IIRC Gobbles claims that is. That doesn't mean it is by any means, but I'm not ruling it out.

Re:Cheers, Theo

[gorf]

Hold on a minute...

There's nothing to say that this isn't a vulnerability in ssh, nor that is isn't exploitable. I'm complaining about the way it was handled, not the fact that it doesn't exist!

I have seen few "crap" advisories. Most bugtraq postings refer to real vulnerabilities, and the ones that don't are quickly pointed out.

It is important to keep up; the results from those who didn't are well known.

...because 99% of advisories are crap

Then at the very least listen to (hopefully digitally signed) advisories from your own vendor.

Re:Cheers, Theo

[platypus]

Ok, you're right, looked at the source of the last file they released, apache-nosejob.c, and they claim apache+linux2.4 to be vulnerable, also Sun Solaris 6-8 (sparc/x86).

Ok, my server run on 2.2, so I'm safe (just joking ;-)).

Re:Cheers, Theo

[Anonymous Coward]

hmm.. really? what's your IP? ;)

Re:Cheers, Theo

[BlowCat]

$ telnet goatse.cx 22
Trying 209.242.124.241...
Connected to goatse.cx (209.242.124.241).
Escape character is '^]'.
SSH-2.0-3.1.0 SSH Secure Shell (non-commercial)

What a pity, it's not OpenSSH! I'm sorry, I cannot upgrade that hole remotely.

Re:Cheers, Theo

[Spacelord]

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

Hmm ... and what was your ip address again? :)

Re:Cheers, Theo

[transient]

Maybe I should define "crap" a little better. ;-)

I wasn't trying to say that most security advisories are untrue, just that they're made out to be bigger deals than they really are. In particular, I was agreeing with this comment from your post:

I don't see any need to upgrade anything.

Re:Cheers, Theo

[Anonymous Coward]

Personally can't say I'm so thrilled about enabling a significant change in architecture such as privilege seperation in it's first incarnation.

Re:Cheers, Theo

[Sircus]

I imagine he's probably trusting the OpenSSH team who have finally admitted that this simple workaround works just fine.

The dire warnings suggesting upgrades to 3.3 were, as far as I can tell, just a strawman to get vendor assistance in actually getting 3.3 to work. Although priviledge separation isn't a bad idea in principle, I'd question its value when you're still left with 2500 of recently-written, can't-possibly-have-been-thoroughly-audited code in the priviledged half after the 'upgrade'.

Re:Cheers, Theo

[Anonymous Coward]

Yeah, it turns out my (former) place of business had been rooted for almost 3 years, and it never cost us any money! All the ha><ors ever did was launch DOS attacks use us to cover their trails.

Okay, well we DID have to bring everything down for a few days in order to wipe and re-install various boxen, and we DID have to get everybody new passwords, but didn't really cost us any money, just time.

Re:Cheers, Theo

[Anonymous Coward]

Hmm ... and what was your ip address again? :)

It's not like it really matters though. What he fails to realize is that there are a huge amount of script kiddies out there constantly scanning large chunks of address space looking for machines to exploit and use as zombies. The more idiots that say "I don't care about security" and close their eyes and ears and pretend the problem will go away, the worse the situation will become.

Re:Cheers, Theo

[dmiller]

Cheers, Theo, you just cried Wolf for the entire community.

Perhaps you would have preferred to leave the people who need kbd-int authentication hanging out to dry? That's a pretty selfish attitude to take.

Re:Cheers, Theo

[gorf]

I don't think complaining about the fact that I just upgraded my box to a version that was vulnerable (and largely untested) when it was fine in the first place is particularly selfish. YMMV.

well...

[ChrisMG999]

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.

Re:well...

[mr_gerbik]

what company would that be?

oh.. microsoft. HAHAHAHAHAHAHAHAHAHAHAHAHAHA!

microsoft totally sux0rz d00d! n1c3 j0k3!

Re:well...

[Anonymous Coward]

Whoever modded this "informative" needs to look up that word in a directory. "Troll" or "Flame bait" would have been a lot more appropriate.

OpenBSD

[return 42]

I notice that OpenBSD, which used to say something like "four years without a remote hole", now says "One remote hole in the default install, in nearly 6 years!" Don't know when it changed - would this be the "one", then? Anyone know?

What is ChallengeResponseAuthentication?

[rherbert]

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?

Re:What is ChallengeResponseAuthentication?

[Anonymous Coward]

S/KEY is for one-use (disposable) passwords. Once used, can't be used again. IF you want extra security you might want to use this.

Re:What is ChallengeResponseAuthentication?

[diamondc]

s/key auth. is a one time use password system. first, you'd generate some passwords and write them down.the passwords only work once. They come in handy if you're in an insecure network.

http://www.openbsd.org/faq/faq8.html#SKey

Re:What is ChallengeResponseAuthentication?

[rherbert]

Ahh, thanks. (I looked through the man pages quickly, but couldn't find a description like you gave.) I just wanted to make sure it was something I didn't need before I went disabling it on all my servers. Thanks!

Re:What is ChallengeResponseAuthentication?

[Anonymous Coward]

RedHat 7.2 (at least) does not come compiled with support for either of the vunerable options.

/* Define if you want S/Key support */
/* #undef SKEY */

/* Define if you have BSD auth support */
/* #undef BSD_AUTH */

Re:What is ChallengeResponseAuthentication?

[D_Gr8_BoB]

None of the Redhat 7.x series are vulnerable. To quote from the advisory:

OpenSSH supports the SKEY and BSD_AUTH authentication options. These are compile-time options. At least one of these options must be enabled before the OpenSSH binaries are compiled for the vulnerable condition to be present.

Both of these options are disabled unless specifically enabled with when configure is run. None of the Redhat 7.x OpenSSH spec files mention anything about BSD auth or SKey support, and so I conclude that they are not vulnerable.

Re:What is ChallengeResponseAuthentication?

[Secure42]

As we can read from: http://www.openbsd.org/faq/faq8.html#SKey

S/Key is a ``one-time password'' scheme. This allows for one-time passwords for use on un-secured channels. This can come in handy for those who don't have the ability to use ssh or any other encrypted channels.

Then why the hell is enable by default in OpenBSD sshd daemon?

Re:What is ChallengeResponseAuthentication?

[Scott Wunsch]

Then why the hell is enable by default in OpenBSD sshd daemon?

Okay, so you're using SSH. Your network traffic is all nicely secure and encrypted, and nobody can sniff your password. But then you sit down in an Internet cafe somewhere, install a copy of PuTTY, and cheerfully log into your server. Obviously, PuTTY asks you for your password. You just type it in and go, right?

Well, what if somebody had installed a keyboard sniffer on that machine? It's a public machine operated by a relatively unknown third party; there are lots of ways it could happen.

With a one-time password, this wouldn't be as big a deal.

Re:What is ChallengeResponseAuthentication?

[Citizen of Earth]

it's for s/key authentication, but what is that? How common is this authentication method, and who would use it?

And if nobody uses it, then why does Red Hat enable it in their default configuration?

Re:What is ChallengeResponseAuthentication?

[Anonymous Coward]

With a one-time password, this wouldn't be as big a deal.

Unless you use OpenSSH 3.1 in which case you wouldn't need a password! :-)

Re:What is ChallengeResponseAuthentication?

[Anonymous Coward]

What are you talking about?

Well, what if somebody had installed a keyboard sniffer on that machine? It's a public machine operated by a relatively unknown third party; there are lots of ways it could happen.
With a one-time password, this wouldn't be as big a deal.

The one-time password (OTP or S/KEY ) described in RFC 2289 is the way how to send the password over network.
Problem is only in the fact that you have to feed the OTP calculator with the challenge and the real password. Returned response (the OTP) is the thing that you can send over the network or type on sniffed keyboard without any fear.
In the situation you describe the OTP calculator have to be running on different computer in order to eliminate risk associated with the keyboard snifing.
I dont think that you would be serious and tried to calculate OTP out of your head. In most of the cases you have only short time to generate the response.

Re:What is ChallengeResponseAuthentication?

[Dahan]

You don't know how to use s/key... if you don't have a s/key calculator to take with you, print up a few passwords before you leave for the Internet cafe and keep the list in your wallet. You don't have to calculate the passwords in your head.

Re:What is ChallengeResponseAuthentication?

[autocracy]

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

Re:What is ChallengeResponseAuthentication?

[dmiller]

Redhat installations may be vulnerable if they have enabled PAMAuthenticationViaKbdInt.

Re:What is ChallengeResponseAuthentication?

[D_Gr8_BoB]

Er... the .spec file is the part of the source RPM that details how the package is built.

Re:What is ChallengeResponseAuthentication?

[autocracy]

The .spec file is contained within the source RPM and hence is extractable. Besides, I'm not aware of an archive of just .spec files for Red Hat (though they most likely exist).

Re:What is ChallengeResponseAuthentication?

[Znork]

True. However, it isnt really used that often, and I'd say the OpenBSD folks have ignored their own best practices of turning off all unnecessary features in this case.

Re:What is ChallengeResponseAuthentication?

[Anonymous Coward]

They don't. OpenBSD does.

Easy workaround

[garett_spencley]

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

Re:Easy workaround

[walong]

Y'know, telnet is secure as long as you're not using it. Ironically, it probably WOULD be safer than leaving an exploitable openssh running. Sure, it's plain text, and therefore vulnerable to packet-sniffing. But most versions of the daemon are pretty safe, and not susceptible to remote exploits via the TCP port.

Re:Easy workaround

[ajs]

ChallengeResponse... oh please! Telnet's never had these problems.

I know you were trying to be humorous, but keep in mind that telnet *does* support challenge-response via the pam system under Linux and most modern systems.

Re:Easy workaround

[chrsbrwn]

You might want to check out this CERT page...

Remember... all software sucks :)

okay, let me get this straight.

[Dr. Awktagon]

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:

It is possible for a remote attacker to send a specially-crafted reply that triggers an overflow. This can result in a remote denial of service attack on the OpenSSH daemon or a complete remote compromise.

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:

At least one of these options must be enabled before the OpenSSH binaries are compiled for the vulnerable condition to be present. OpenBSD 3.0 and later is distributed with BSD_AUTH enabled. The SKEY and BSD_AUTH options are not enabled by default in many distributions.

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! $-)

Re:okay, let me get this straight.

[Anonymous Coward]

you charge by the hour to upgrade client's machines? i hope you dont use debian, 'cos you'd be a poor man it you did :-)

Re:okay, let me get this straight.

[Dr. Awktagon]

ha ha.. it looks like many of my machines already had "ChallengeResponseAuthentication no" for at least the last few months. I'm going to go beat myself in the head with a brick now.

Re:okay, let me get this straight.

[nestler]

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.

This was not "security by obscurity". They just waited a few days before releasing the details. When MS gets notified of a bug, they sit on their ass for a month before releasing a patch that doesn't work. In the meantime, they say nothing.

The OpenSSH team got the fix in in less than a week, and gave you enough information to cover your ass in the meantime. I think the whining here about this episode is way out of hand considering the OpenSSH team's very quick handling of this bug and past bugs.

Re:okay, let me get this straight.

[zrodney]

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.

Re:okay, let me get this straight.

[jred]

ha ha.. it looks like many of my machines already had "ChallengeResponseAuthentication no" for at least the last few months. I'm going to go beat myself in the head with a brick now.

You need to get a girlfriend. Then *she* can smack you w/ a brick. Seriously, my gf recently started to carry a brick in her purse. Now if I get out of line she just tosses it from hand to hand & I straighten up real quick :)

Re:okay, let me get this straight.

[dmiller]

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

Actually you may be vulnerable if you have PAMAuthenticationViaKdbInt set as well.

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.

No, a release with a workaround (privsep) was distributed to give people a chance to immunise themselves before the real problem was publicised.

That stinks, if you ask me.

Nobody did.

MacOSX update ?

[selderrr]

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

Re:MacOSX update ?

[Anonymous Coward]

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

How can you have a single hole, and still be 100 times more secure??? That'd be 0 times more secure in my book.

Re:MacOSX update ?

[jahndm]

(1) Mac OS X 10.1.5 (the current version) has "OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f" installed.

(2) 1 bug being "100 times more secure than 95% of the market" implies that the 95% of the market has 100+ bugs. Safe assumption.

Re:MacOSX update ?

[cthrall]

> If they don't, welll, they're still a 100 times
> more secure than 95% of the market

"Mac OS X Server also includes...the most reliable releases of Apache"

Well, maybe 50 times.

Re:MacOSX update ?

[mckayc]

What was the purpose of this comment? And why the hell was it modded up?

Re:MacOSX update ?

[Anonymous Coward]

AFAIK, OS X does not have support for challange response systems (aka S/Key or OPIE), so it should not be affected. I am looking forward to Apple releasing a statement that it is safe, or an update, if it isn't.

Re:MacOSX update ?

[Anonymous Coward]

Nobody reads your book. Go away.

Re:MacOSX update ?

[ellem]

I read his book, it was very boring.

(Flamebait -1 again)

[SL33Z3]

Gee, I don't sense the same cynical tone that you might see if this were a Microsoft product. I can't imagine that could have anything to do with bias on this site would it? NOoooo Not here. We just want the truth right?

Re:(Flamebait -1 again)

[Anonymous Coward]

Are you kidding me? Look at all the people trashing the way Theo and ISS handled this. To me, they did a good job. Let me know their is an exploit and give me a workaround for it, WITHOUT giving unnecessary informaion to the script kiddies, and then release the full details when the patch is ready, a few days latter.

For doing all that, they get flamed to hell. If it was me, I would say "fine, you guys don't like it? Next time I'm fixing my OS implementation (OpenBSD) without telling anybody, then I will release the bug and an exploit for it, and you can all burn in hell, you ungratfull bastards. It's not like you PAY for this stuff"

Re:One Word "Gobbles"

[toupsie]

I thought that was the Apache 'sploit on OpenBSD systems. Private Distro channels? What is that? P2P for script kiddies?

Gobble! Gobble!

bug #285

[Garion911]

But have they fixed this bug??

This is a showstopper for me. Turning compression off does not solve the problem for me. I ended up using some patch off the mailing list temporarily.

Re:bug #285

[rebrane]

Solar Designer wrote a patch for 3.3p1. It'll probably work on 3.4 as well.

Re:bug #285

[Garion911]

Nope it doesn't. Just checked the code. Applying cheesy patch. Argh.

Re:bug #285

[Scott Wunsch]

This is a showstopper for me. Turning compression off does not solve the problem for me.

Well, I installed OpenSSH 3.4p1 on a machine running kernel 2.0.38, and it's working fine. I didn't have to mess with any extra patches, or with the Compression setting in the configuration.

What version does OSX ship with?

[Jekyll]

Does it even ship with OpenSSH installed? I'd be intrested to see if OS X is vulnerable - FreeBSD-STABLE isn't, so I wouldn't be surprised if OSX was using a pre 2.9.9 version.

Re:What version does OSX ship with?

[mithras the prophet]

Welcome to Darwin!
[mithras:~] mithras% ssh -V
OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f

and
cat /etc/sshd_config
...
# 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...

Re:What version does OSX ship with?

[ZerothAngel]

It seems like we might be vulnerable. If you ssh -v localhost, you'll see this:

debug1: authentications that can continue: publickey,password,keyboard-interactive

The presence of keyboard-interactive would seem to imply that ChallengeResponseAuthentication is on.

Re:fsshd post

[Anonymous Coward]

no.

For gods sake

[Mr_Silver]

Never have I seen such a pathetic display of whinging. Bug was found, 3 choices:

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.

Re:For gods sake

[Ranger Rick]

The issue is not that they put out a "fix", it's that they put out a fix + a bunch of other new and untested-in-the-wild code.

On stable, production machines, I don't want to update to foo-bar version ++32, I want the exact same thing that I run now that is stable and otherwise tested, but with the security fix applied.

I'm sure all these new features in the latest OpenSSH version are great, but until people can test them longer than a small core of OpenBSD developers running from CVS, there's no way in hell I'm replacing my otherwise stable and working version. I'm going to patch the one thing that's exploitable right away, and then *test* the new version, and release when it's confirmed to be OK and stable in my environment.

I would much prefer #2, so that I can fix it immediately, and the evaluate the next full release that properly incorporates those changes.

Re:For gods sake

[tzanger]

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.

I agree. 1 is better than 3, but 2 is what he has been doing for a long long time. This was a stunt to try and make everyone upgrade to 3.4 with the nifty privsep code that isn't fully working on all platforms yet. I suppose he's running out of alpha/beta testers and needed more or something.

Re:For gods sake

[DustMagnet]

Sure, given your choices that's best, but they could also:

A. Tell me that it only effects a small portion of installed systems.

Geesh, why make it sound like everyone had this problem?

Re:For gods sake

[epine]

Hear, hear!

Re:For gods sake

[esper]

You forgot:

4. Announce that there is a bug in certain versions when built with certain options (so that those of us who aren't vulnerable in the first place know not to panic).

Re:For gods sake

[VB]

Or, just fix it yourself if you're uber. >:)

(Don't forget Compression no on linux-2.2.x)

Re:For gods sake

[Buck2]

U shuld h4ve speeled it: whining!

Whinging is p0mpus and br1t!!

stupid-head

Re:For gods sake

[David Jericho]

If that's your attitude to securing your systems, go back to Microsoft.

I've been aruging this point with Theo's Fan Boys for the last few days, and none of them seem to get it. Let's review what my actions would have been in each of the above scenarios.

1. I may have been rooted. I'd get agro at Theo because he didn't inform us when he knew. If he knew, blackhats knew too.
2. Disable sshd on my systems. I use RedHat because I know they put a fair bit of QA onto their releases. I know people use Debian or many other OSes for the same reason. Wait for a QA tested, and fixed version to come out. Avoid using the known buggy version as a temporary fix.
3. Disable sshd on my systems. Assess the risk to me, and as to if the bad code has any relevence to me, and if it can be disabled by a feature switch. Make a choice based on the information given to me, and continue on my way.

It's not Theo's job to ensure my systems are secure. It's mine. This is the premise behind full disclosure, letting me make the judgement call on the information given to me. If I choose to ignore Theo, and get hacked, it's my fault, and my fault alone for ingoring the information given to me.

The security world isn't a fair one. The good guys only have access to what the other good guys share. The bad guys have access to both worlds. Like I said before, if Theo knows, chances are there's at least one bad guy out there that knows.

Re:For gods sake

[sjames]

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.

4. Tell reputable distro maintainers exactly what the problem is while the bug is fixed. Let the maintainers figure out what their user base needs to do.

Number 4 is especially important in the situation with OpenSSH. Many who did the upgrade BECAME vulnerable to the lesser non-root expolit when the version they 'upgraded' from had no known holes! That would have been averted if distro maintainers had been in the loop.

Where are the vendor statements?

[embobo]

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

Better workaround: Mandrake

[Anarchofascist]

"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

All these problems wouldn't happen

[SpanishInquisition]

...if we still used telnet.

Probable Reason for Theo's Approach

[Foresto]

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?

Re:Probable Reason for Theo's Approach

[esper]

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?

Re:Probable Reason for Theo's Approach

[gorf]

Apart from the lack of social grace that he's famous for, I'd say Theo handled this about as securely as he could.

Yes, he did.

Moreover, he did so by folloing the procedure widely accepted in the security community.

No, I don't think he did. Normally the exploit is announced at the same time as the fix or workaround. Instead of this, he told everyone to upgrade (which is an unnecessary inconvenience for at least some people, who could just use the workaround). He has basically forced us to (unnecessarily) upgrade to a version which has known problems.

I don't think this is standard practice, but clearly it isn't a standard situation (ssh is the one thing that locked-down boxes still may have open, and the upgrade conveniently stopped the exploit without giving it away). I'll admit that whether or not he did the right thing isn't clear cut, but I don't think he did.

With every other exploit/fix that's announced there's a "Window of Exposure" during which you are vulnerable, and that was still the case here. The only difference is that there was a chance that fewer people knew about it. But given that the exploit was found, there's no reason that it hasn't already been actively exploited for a while by black-hats.

It's generally accepted that there's always going to be a "Window of Exposure", and that the way to keep this to a minimum is to coordinate the announcement of the exploit with the announcement of the fix. I don't see why that couldn't have been the case here.

While I accept the advantages of his approach, in my particular case the disadvantages far outweigh them (if I had decided to upgrade all the boxes I'm responsible for, this would have taken me maybe about 36 hours and many remote reboots. Had I messed up then entire businesses would have gone without functional computers). My problem is that he made the decision for us, and this is exactly what full disclosure is not supposed to do.

Re:Probable Reason for Theo's Approach

[Bishop]

Except in this case the vendors, such as Debian, didn't have any head start. As per the above post Theo didn't tell the vendors anything either.

Re:Probable Reason for Theo's Approach

[Spacelord]

> I had decided to upgrade all the boxes I'm responsible for, this would have taken me maybe about 36 hours and many remote reboots

If you need a remote reboot to upgrade ssh you need to work on your Unix skills I'd say ....

Seriously ... all you have to do is install the new version over the old one, kill $(cat /var/run/sshd.pid) and restart sshd.

I just did 3 systems like that in under 30 minutes (started the compile in parallel of course).

Re:Probable Reason for Theo's Approach

[gorf]

Not quite. Our machines boot down a 64k ISDN link. I could get away with upgrading ssh manually, but then it won't stay after a reboot. To do that, I have to integrate it into our existing system for upgrades, which involves a reboot (for us, a scheduled reboot outside business hours isn't a big deal, so our internal system doesn't bother to cope otherwise as it's extra unnecessary effort).

Re:Probable Reason for Theo's Approach

[PD]

I just my three systems in 30 seconds. I was already logged into each one, so I did

>su -
>apt-get update
>apt-get upgrade

All done.

Re:Probable Reason for Theo's Approach

[rabidcow]

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?

From every programmer ever? It's pretty standard when reporting a bug to get "please upgrade to the latest version and try again." Nobody wants to have to go back and fix bugs in every version of every program they've ever written.

Re:Probable Reason for Theo's Approach

[esper]

From every programmer ever?

Nope. I guess I just forgot that the Debian security team, which backports security fixes, is an anomaly.

More seriously, though, one of the often-touted benefits of open source/free software is that we produce security patches which don't introduce hordes of new features (and bugs). It's sad to see good projects starting to behave like proprietary software vendors and doubly so that it would be something as respectable as openssh.

Re:Probable Reason for Theo's Approach

[Spacelord]

That's all nice and dandy if you run Debian ...

Unfortunately in the real world I have to deal with other systems too, like AIX and older RedHat systems (We have to stay on RedHat 6.2 on some systems for application compatibility with a 3rd party app)

So I do have to install from source a lot of the time. The upside is you get to know better what gets installed on your system but on the other hand it does get old installing OpenSSH for the umpteenth time.

Slackware not vulnerable

[volkerdi]

Slackware is not affected by this security problem. You need BSD_AUTH, S/KEY, or PAM to have a potential problem (PAM is still not verified), and we've never compiled in any of those options, nor are they options in a default build. So, you could just keep using a version with working compression, just don't include those options.

More simple is usually more secure.

Re:Slackware not vulnerable

[Anonymous Coward]

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.

Re:Slackware not vulnerable

[|<amikaze]

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

[joe_fish]

... is that on the 2 RedHat 7.3 boxen I have access to already have "ChallengeResponseAuthentication no" - so I guess this means I'm not vulnerable?

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.

Re:The good news ...

[rebrane]

I don't think ANY Linux system is vulnerable unless they SPECIFICALLY compiled in S/KEY support. No Linux distros that I know of do this. It's a BSD thang.

Re:The good news ...

[volkerdi]

A lot of them compile in PAM, though. The bug involves keyboard-interactive mode plus one of the following: BSD_AUTH, S/KEY, or PAM.

Re:The good news ...

[Anonymous Coward]

7.2 is configured as yes (Just switched it myself :P).

Probably a good thing, too, I keep getting hit with OpenSSH version scanning out of Korea. >:P

Re:The good news ...

[RedHat Rocky]

Where do you see this?

From the advisory from ISS X-Force:

"OpenSSH supports the SKEY and BSD_AUTH authentication options. These are
compile-time options. At least one of these options must be enabled
before the OpenSSH binaries are compiled for the vulnerable condition to
be present. OpenBSD 3.0 and later is distributed with BSD_AUTH enabled.
The SKEY and BSD_AUTH options are not enabled by default in many
distributions. However, if these options are explicitly enabled, that
build of OpenSSH may be vulnerable."

Granted, ISS X-Force is proving to be the bad child in the group, they may once again be inaccurate in their race to get "credit".

Re:The good news ...

[Anonymous Coward]

>>I get the feeling this was is a molehill made into a mountain.

Possibly, though better than presenting mountains as molehills. The privsep stuff is a good idea in any event, as it immunizes not only against this 'sploit, but potentially future ones. Surrounding this one in a dire mountain tone is bad for credibility which is unfortunate, but will have generally positive effects as I'm sure many sysadmins like myself found ourselves feeling rather motivated to do something we probably should have done anyway.

[OT] ISS

[elam]

IMO, this is the way ISS should have handled the Apache advisory...

Wait a minute

[essdodson]

I thought Open Source meant secure? You've all been lying to me, you bastards!

Re:Wait a minute

[getter_85]

Go back to your windows box and SHUT THE HELL UP.

How to fix ...

[joe_fish]

Just add a line to your /etc/ssh/sshd_config like this:

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.

Re:How to fix ...

[ComaVN]

Thanks! I just did this. Thank god linux is so easy to configure.
btw. my ip address is 127.0.0.1, could you check it out?

Re:How to fix ...

[Anonymous Coward]

Just add a line to your /etc/ssh/sshd_config like this:

CheckPasswords false

Done!

And then reboot your sshd.

Done!

My IP is 198.137.240.92 . Please reply soon!

Re:How to fix ...

[Anonymous Coward]

Damn. I just ssh to the President. Now ..WHA?

GWB: All your ssh are belong to us!

Oh fuck.

Re:This is a GREAT day for muslims

[Anonymous Coward]

hiho to jal and all my dead homies btw.

muslims: foad kthx.

I like the new slogan...

[bluebomber]

the openbsd website has been updated:

One remote hole in the default install, in nearly 6 years!

*sigh*

Fun while it lasted, I guess...

Re:I like the new slogan...

[Anonymous Coward]

As more and more software gets added to OpenBSD, they'll need more and more eyes. (Or the same amount of eyes, and more time.)

Naturally, however, it'll get increasingly harder to spot every bug.

But tell me.. One remote hole, in nearly six years? Call me crazy, but that's *damned* impressive. :) I wish my Linux distro could make that claim.

I think I'm going to order an official copy of OpenBSD. I may never use it, but I'm willing to bet that they find a lot of security flaws that others miss, and that benefits everyone - BSD and Linux.

Re:I like the new slogan...

[alexandre]

Should have been: No remote hole in the default install for 48 hours! :-)

Re:I like the new slogan...

[archen]

hope they don't find another one. Then they'd have to change it to. Appx one remote hole every 3 years (avg) - and that doesn't sound right.

RH 7.3 rpms mirror

[Hoonis]

anon ftp mirror of the rh7.3 rpms (and source rpm) here:

ftp://wingnut.beimborn.com

10k/sec cap, but they are small packages

DB

Re:Post predictions

[Anonymous Coward]

dont forget the 10000 people posting exaggerated predickted post numbers.

Affects who?

[MSG]

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

A Question

[Wrexen]

This is not a troll/flamebait. Mods, keep your pants on.

If OpenSSH is open source, and it is known that there *is* a hole in it, why are people on /. running around like chickens with their heads cut off clammoring about how the person who found it should tell us what it is? The whole idea is that "many eyes ..." so why didn't we just go out and find it?

Re:A Question

[Anonymous Coward]

Ya, sure. You do that.

Sometimes people spend weeks researching things like this, or stumble across them by accident.

Well, the next time there's a problem, and everyone's hush-hush about it, i nominate you to locate and fix the problem.

Re:A Question

[John Hasler]

So how long did it take you to find the bug? And why didn't you tell us about it?

Code Audits, the UNIX security model

[Nerant]

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

Re:Code Audits, the UNIX security model

[fw3]

suggest you go have a look at LSM - Linux Security Module ... see the .mp3 of the lsm presentation at this weeks kernel summit at lsm discussion. LSM creates hooks in the kernel functions which are security relevant (about 150) and can mitigate access to a couple dozen kenel data structures.

security model is too coarse grained: ... move towards ACLs, for example in NSA's SE Linux, as well as LIDS

Actually SELinux does not implement ACL's, but rather Type Enforcement. It also has potential (and experimental impementation) to implement MLS or other security policies / methods.

What type enforcement gets you is the ability to create highly fine-grained security controls, so that the program and user-security-context have privilege to execute critical functions and that privilege can be removed from the root user.

One of the debian SELinux implementers placed an SELinux system on the 'net with root-password / ssh access advertised. This is not a proof of safety, but in fact noone succeeded in escalating privilege.

As it looks like LSM is on track to be in kernel 2.6, at least the way is presently paved.

Do I assume this is set at no?

[antdude]

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

Re:Do I assume this is set at no?

[RollingThunder]

Generally, the defaults are displayed in the config file, as commented out instructions. In other words, the default is yes.

Screw OpenSSH -- I'm going back to commercial SSH

[Anonymous Coward]

Stupid security holes.

Theo DeRaadt's code writing ability resembles a chunk of swiss cheese that has been blasted a few times with some shotgun rounds.

And this NASTY HOLE keeps getting ignored, but the OpenSSH team continues to fix others.

Screw this -- I'm going commercial UNiX.

Does this only affect _Open_SSH?

[Trevin]

Each time I see a vulnerability report about OpenSSH, I wonder whether the vulnerability is also present in plain SSH. Finland's site doesn't seem to have any information on security advisories, at least not in any obvious place.

Summary?

[Snafoo]

Is there a page anywhere that summarizes the holes/bugs/exploits in OpenSSH discovered in the last, say, two years? year? six months?

Compression and 2.2.x kernels?

[cjpez]

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?

Re:Compression and 2.2.x kernels?

[D_Gr8_BoB]

It's still broken, but at least now it'll tell you they don't work together rather than just breaking.

Re:Compression and 2.2.x kernels?

[VB]

Put the following in sshd_config:
Compression no

(How fast do you actually type, anyway?)

Re:Compression and 2.2.x kernels?

[cjpez]

Yeah, I knew how to disable Compression, just wanted to know if I still had to before upgrading . . . I suppose I could have just tried it out myself, but why waste my time when I can waste my time AND someone else's at once? :P

As to the typing, if that's a serious question, I tend to type pretty quickly. Couldn't give you a WPM, though. Why the query?

Re:Compression and 2.2.x kernels?

[gbroiles]

Compression doesn't help make interactive keystrokes go faster, it helps make interactive screens refresh faster; but the big win is for non-interactive stuff, like tunnelled HTTP or SMTP or POP; or file moves, via scp or sftp. That's where compression makes a big difference, and why it's a bummer to turn if off unless absolutely necessary.

Re:Compression and 2.2.x kernels?

[VB]

...Why the query?

Just a rough stab at British humour... Not very funny, I guess. >:)

Re:Compression and 2.2.x kernels?

[cjpez]

Aaaaaah, no, I've got it now. :) Not terribly funny, but not bad, either. :)

Re:Jesus, Paranoid or What?

[Anonymous Coward]

No, he's right. The way Theo dealt with the vendors was fucking obnoxious.

I'm not impressed

[Anonymous Coward]

There was a simple workaround in the config file and they made people waste time f*cking about with that messy new version. It's all about politics and ISS milking it for publicity.

Nice advert for not using open source s/w, your at the mercy of idiots, I was converted one way a few years back, now im advising people to steer well clear.

3.4 is a double-edged sword on Solaris

[koreth]

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

Re:3.4 is a double-edged sword on Solaris

[antijava]

3.4 doesn't even compile on Solaris 5.8:

gcc -g -O2 -Wall -Wpointer-arith -Wno-uninitialized -I. -I. -I/usr/local/ssl/include -I/usr/local/include -DSSHDIR=\"/usr/local/etc\" -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/s sh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/local/libexec/sftp-serv er\" -D_PATH_SSH_KEY_SIGN=\"/usr/local/libexec/ssh-keys ign\" -D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DSSH_RAND_HELPER=\"/usr/local/libexec/ssh-rand-he lper\" -DHAVE_CONFIG_H -c canohost.c
cc1: warning: changing search order for system directory "/usr/local/include"
cc1: warning: as it has already been specified as a non-system directory
canohost.c: In function `get_remote_hostname':
canohost.c:68: warning: implicit declaration of function `getnameinfo'
canohost.c:91: warning: subscript has type `char'
canohost.c:108: warning: implicit declaration of function `getaddrinfo'
canohost.c:120: warning: implicit declaration of function `freeaddrinfo'
canohost.c: In function `check_ip_options':
canohost.c:153: warning: implicit declaration of function `getprotobyname'
canohost.c:153: warning: assignment makes pointer from integer without a cast
canohost.c:154: dereferencing pointer to incomplete type
*** Error code 1
make: Fatal error: Command failed for target `canohost.o'

I'm sure glad I'm not required to move to 3.4 to plug the hole...

Re:3.4 is a double-edged sword on Solaris

[Anonymous Coward]

If you look at "configure" for OpenSSH 3.4, it looks to see if MAP_ANON is defined in /usr/include/sys/mman.h.

In Solaris 8, it's present. In Solaris 2.6 and 7, it's not.

So, that means "HAVE_MMAP_ANON_SHARED" isn't defined in Solaris 2.6/7, and as a result, in servconf.c, you hit

#if !defined(HAVE_MMAP_ANON_SHARED)
if (use_privsep && options->compression == 1) {
error("This platform does not support both privilege "
"separation and compression");
error("Compression disabled");
options->compression = 0;
}
#endif

Gee, real "portable" code there, Theo. Thanks for encouraging us to "upgrade" just to use a "feature" that isn't even possible to use in anything but the latest Solaris release, and with no warning that it can't be used (and thus shouldn't be enabled in the command-line options when you run configure on Solaris 2.5/2.6/7 platforms).

Prat.

Yes: http://www.openssh.com/security.html

[David McBride]

(See subject.)

Are people really that dense...

[Steveftoth]

that you have to say in your post.... (this is a joke)

But, after reading /. for as long as I have, I guess that it's true, some people are just humor impared.

still getting buffer overflows huh?

[hqm]

Maybe if people stopped programming in
C they wouldn't keep having integer overflow
and buffer overflow bugs. This has been a solved
problem in Lisp forever.
Even Java has integer overflow, the C weenies never really learn to part with their old ways.

Re:still getting buffer overflows huh?

[Anonymous Coward]

C weenie? Please.

Java is the pansiest language of them all.

Re:still getting buffer overflows huh?

[gorilla]

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.

Re:still getting buffer overflows huh?

[Anonymous Coward]

You're gonna build an SSH equivalent in Lisp, eh? Or Java? I won't hold my breath.

Serious/high-demand work demands a serious and highly capable language. Avoiding such things as buffer overflows is a matter of discipline, not language; a serious and capable progammer knows these things. Even still, we're all only human.

Try something else.

[TheLink]

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.

How soon until djbssh?

[GregGardner]

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.

Re:How soon until djbssh?

[Anonymous Coward]

djbssh...

Yep, installs in /mnt/secure_service by default, changing the location results in a court order.

Security is not everything in software you know...

Re:How soon until djbssh?

[GregGardner]

Security is not everything in software you know...

It is in a product called Open Secure Shell.

Re:How soon until djbssh?

[JeMoerIsEenHoer]

You will see a remote root compromise in Qmail very soon. I have said...

telnet+SSL+certs

[TheLink]

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.

Re:telnet+SSL+certs

[Zaffle]

I've been using stunnel+telnet for years and I have had to patch/upgrade a lot fewer times than people using SSH.

Hmmm, funny, IIRC (if I recall correctly), this is the first time an upgrade of OpenSSH has been required. Sure, upgrades are always around for fixing various bugs, but this is the first remote security hole bug.

(Ok, now I think about it, there was that Linux local root comprimise w/ openssh, but that wasn't remote, and afaik, linux only).

Although telnet+SSL+certs can be safer, it requires a lot more setup and general maintaince.

The most secure box is the one under my couch. Its got no screen, no keyboard, no floppy, no network, and its OFF!

Re:Where are the vendor statements? FALSE

[Anonymous Coward]

Not true. My RH 7.2 and 7.3 systems default to "no". In fact, you can't set it to yes because support isn't even compiled in.

My complaint

[Bandito]

My complaint is that they forced everyone to upgrade to 3.3 (which is by all accounts largely untested) to workaround this problem when all that was needed was to set a single option to no in the config file.

I certainly would have preferred to do that to upgrading to an untested version of software.

Re:My complaint

[argel]

And what are the people who are using Challenge/Response supposed to do???

Re:My complaint

[Mr_Silver]

My complaint is that they forced everyone to upgrade to 3.3

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.

Maybe not hordes....

[Bodhidharma]

There are crackers out there and it is important to keep up with security advisories. I just have to check my Apache logs to see attempts to exploit old IIS bugs. My system logs show the occasional attempt to hit SSH as well.

Of course I use ipchains and tcpwrappers so I don't worry too much about SSH exploits but I still make the effort to keep up.

FUD comes to open source

[OpenMind(tm)]

This is one of the first times I've seen someone in the open-source community try to use fear-uncertainty-doubt to get their user base to upgrade whether they need to or not. It turns out, that for all Theo de Raadt's sense of urgency that everyone should upgrade, we're not vulnerable at all where I work, because we disable auth mechanisms that we are not using. I tend to believe that Theo knew that this would effect less than half of the ssh community. Even for most of us with it compiled in, there is a one-line workaround that could be deployed much more quickly than a new version. While the new privilage separation code sounds like a really good idea. Still, to me the whole drama seems like an attempt to provoke the whole community to upgrading when they really didn't need to.

Re:FUD comes to open source

[Anonymous Coward]

You dumbass...what about all the IIS exploits that relied on those strange extensions like .idq, .ida, .htr, etc...if you had them disabled then you were not vulnerable...so does that mean that the whole drama about those holes was just "an attempt to provoke the whole community to upgrading when they really didn't need to"? Workarounds should be temporary, not relied on for any extended period of time, especially when a fixed version is available. My servers weren't vulnerable to the SQL overflows because my firewall blocked 1433...I still patched the darned boxes...If you were in charge of securing my systems i'd be pretty unhappy if you chose to use vulnerable versions of software with workarounds rather than versions without the holes.

Another theory goes down the drain

[TheCabal]

So much for the "many eyes, open source, no bugs" theory. And what's with they delayed announcement? Open-source taking a few clues from the Dark Side?

Re:Another theory goes down the drain

[A Non-MS Coward]

You clearly know nothing of what you mock.

The "many eyes" theory doesn't promise "no bugs". A programmer sitting at a desk coding away is just as likely to have n number of bugs whether he intends to license it open, closed, or is undecided. Same coder, same code. The license itself doesn't stop the bugs.

Do you know what "many eyes" even do? They read code, find the bugs, and fix them. Most vulnerabilities under this system are found and fixed before they're exploited in the wild.

Compare to a closed system, pick a popular one if you like. No code to review, very few eyes. Bugs are found by black hats pounding away at unsuspecting boxes. Find an exploit, get it out into the wild, and then get out your calendar and wait for the fixes.

So take your pick.

This is getting silly

[cprice]

I probably upgrade OpenSSH more than any other service on my systems. How in the fsck am I supposed to keep up with this in a production environment? What does the frequency of bug release indicate about the 'thorough' coding practices over at the OpenBSD group? I'm not trolling - just asking what I consider to be legitimate questions.

Re:This is getting silly

[Anonymous Coward]

Well, here is a legitimate answer:
shit happens :)

Really though, developers are doing their best, since they rely heavily on OpenSSH themselves.

Lets say we assume this to be a trojanned binary?

[fw3]

I don't see openssh more recent than 3.1p1 on redhat.com and I don't see any verification / md5 signatures / whatever.

No offense intended but this looks like an attempt to take rubes (the poster's 26+ karma notwithstanding.

I'm not impressed.

[Anonymous Coward]

There was a clean work-around and they didnt post it.

I believe bastille does this for you

[Anonymous Coward]

I manage 5 systems here. One was hardened by bastille linux. On that system, it was already set to ChallengeResponseAuthentication no.

So I think the bastille scripts fixed the setting.

Red Hat too?!

[alienmole]

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.

Fuck it.

[xmutex]

I'm going back to telnetd and blind optimism.

Re:Screw OpenSSH -- I'm going back to commercial S

[BumbaCLot]

Warning goatsex link

Re:Transient's IP

[Anonymous Coward]

start here

This all could have been avoided...

[chrsbrwn]

Meaning this brouhaha, of course...

Just to combat some of the misinformation that has been spreading around here:

• privsep is not a "new" feature... it has been available since OpenSSH 3.1p was released, almost 2 months ago. In that two months none of the various vendors and users who are whinging now appear to have bothered to help the openssh team test the privsep code and develop patches to make it work better.
• With privsep enabled, this hole, and any future root hole are made much more difficult, sometimes even impossible, to exploit. Privilege separation is just the right way to code network daemons -- postfix does it, apache does it, courier imap does it, qmail does it -- and now, openssh does it. It is a bit more complicated for openssh to do it because it needs to interface directly with some operating system facilities like authentication, PAM, etc that require root privileges.
• I installed 3.3p yesterday on all of my network facing systems, and will be upgrading to 3.4 as soon as Debian has it available -- I firmly believe in the concept of privilege separation, and will always seek out network daemons that use it.
• I thank the Debian team, OpenBSD/OpenSSH teams, Wietse Venema and the rest of the Postfix hackers, the mailman team, the GNU project, all the Linux kernel hackers, and anybody else who has contributed free software that I rely on to do my job for making my job as a sysadmin smoother than it might otherwise be. I know the alternative, because I am also responsible for an Exchange server, and I spend far more time patching that and making sure it is up to date than I do with any of my Debian servers.

Don't complain too much folks... you could have to do without a robust free ssh implementation.

Difference between Theo and the Borg

[bee]

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.

What is wrong with this picture

[nelsonb]

What the hell is wrong with the people at ISS? This is the second "incident" in as many weeks. The message from the Theo at OpenSSH and other Linux Vendors said the info AND the realfix would be released early next week. This certainly seemed like a very responsible method of alerting people. Give everyone a week to upgrade to 3.3 and enable an option that could help mitigate any potential damage and then release a fixed version of the program and the full details. This gives large production houses enough time to get the new version/config through change control and even gives admins who don't read bugtraq lists time enough to hear about throughanother channel. Everything was working out pretty well and ISS has to go and screw up a pretty good plan. Does ISS have a problem with queued up advisories and techs with itchy trigger fingers? Does Time some how run differently in Atlanta? I guess another lame self-justification will be forthcoming from ISS, but there is no excuse for this. What about the little people? Were you in such a hurry to get your X-Press Update advertisement out that you don't even consider the ultimate end-user? Is it so easy to forget that not everyone is in organizations that discover or releases 0-day info amongst themselves? Most administrators don't read bugtraq, and those thatdo received a polite, clear note from Theo:

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 away

Re:What is wrong with this picture

[Todd Knarr]

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.

Re:What is wrong with this picture

[nelsonb]

So it would seem there are deficiencies on both sides. If the simple sshd_config fix was a known issue then it should have been included in his original warning. My personal preference would have been to download the version with privilege separation, because it is a superior way to deal with things both present and future; however, given that this isn't widely tested I could definitely see the usefulness of the "quick fix".

Re:Lets say we assume this to be a trojanned binar

[bruceg]

well, it does have the source rpm, so I guess you could audit it. It would be nice to have the md5sums, though. I'm guessing the author is trying to be nice in building an rpm.spec from the source, and also including some binary builds for RH 7.3

Much easier to do this on RedHat 6.2...

[emil]

...rather than rebuilding. Generating new RPMs for 6.2 is a total nightmare.

Re:Much easier to do this on RedHat 6.2...

[wossName]

Odd, I installed the SRPM, changed all the necessary flags in the spec file and it compiled without a hitch. I do have an up-to-date OpenSSL library, though.

Re:Much easier to do this on RedHat 6.2...

[emil]

Exactly - RH62 requires an older OpenSSL for rpm dependence, but you have to install a newer version to get the SRPM to compile, which means temporarily removing the older OpenSSL RPM.

After you've built the RPMs, you remove the newer OpenSSH, put back the old one, and then when you try to install the OpenSSH RPMs you've built, rpm complains about OpenSSH dependencies, forcing an override with --force (or --nodeps, I can't remember).

I think 6.2 is still alive enough to warrant binaries at openssh.com. This is exactly the sort of thing that my Debian friends say is totally solved by apt.

Re:Much easier to do this on RedHat 6.2...

[wossName]

Why don't you just keep the new OpenSSL version ? If you don't have too much stuff that depends on OpenSSL, rebuilding some packages from SRPM shouldn't be a problem.

Mod parent up

[Anonymous Coward]

"I thank the Debian team, OpenBSD/OpenSSH teams, Wietse Venema and the rest of the Postfix hackers, the mailman team, the GNU project, all the Linux kernel hackers, and anybody else who has contributed free software that I rely on to do my job for making my job as a sysadmin smoother than it might otherwise be."

That's something that could be said more often.

Revised OpenSSH Security Advisory

[RedHat Rocky]

From announce@openbsd.org:

"
This is the 2nd revision of the Advisory.

1. Versions affected:

Serveral versions of OpenSSH's sshd between 2.3.1 and 3.3
contain an input validation error that can result in an
integer overflow and privilege escalation.

All versions between 2.3.1 and 3.3 contain a bug in the
PAMAuthenticationViaKbdInt code.

All versions between 2.9.9 and 3.3 contain a bug in the
ChallengeResponseAuthentication code.

OpenSSH 3.4 and later are not affected.

OpenSSH 3.2 and later prevent privilege escalation if
UsePrivilegeSeparation is enabled in sshd_config. OpenSSH
3.3 enables UsePrivilegeSeparation by default.

Although some earlier versions are not affected upgrading
to OpenSSH 3.4 is recommended, because OpenSSH 3.4 adds
checks for a class of potential bugs.

2. Impact:

This bug can be exploited remotely if
ChallengeResponseAuthentication
is enabled in sshd_config.

Affected are at least systems supporting s/key over
SSH protocol version 2 (OpenBSD, FreeBSD and NetBSD
as well as other systems supporting s/key with SSH).
Exploitablitly of systems using
PAMAuthenticationViaKbdInt
has not been verified.

3. Short-Term Solution:

Disable ChallengeResponseAuthentication in sshd_config.

and

Disable PAMAuthenticationViaKbdInt in sshd_config.

Alternatively you can prevent privilege escalation
if you enable UsePrivilegeSeparation in sshd_config.

4. Solution:

Upgrade to OpenSSH 3.4 or apply the following patches.

5. Credits:

ISS.

Appendix:
"

ISS NOT the good guys anymore

[npsimons]

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

I'm hoping that someone else other than me has notice that this is not the first time that ISS has withheld security information. I applaud the guys at ISS for their efforts, but their delivery could use a little work.

Maybe this is troubling me more than it should, but when I start seeing the community divided against itself, I can't help but think that we will never succeed. I'm not saying there has to be perfect harmony and unity, but withholding security information goes against values that I believe everyone of us holds dear (full disclosure, open standards, systems and source, etc).

Re:Cheers, Theo (can i have your ip)

[Anonymous Coward]

please post your ip i would love to see how this

ignore it and it will go away plan is working for

u.

Ummm.

[Ziviyr]

Is it just me, or does telnet not have these problems? :-)

CERT Advisory.

[hearingaid]

There's a full CERT advisory on the OpenSSH bug and the implications for your particular platform. Sysadmins, read it. Of course, you prolly all got it in your email like me, right? :)

ftp.openssh.org is getting hammered right now... sigh.

Re:CERT Advisory.

[Anonymous Coward]

Hmmm... the CERT advisory workaround is to disable ssh2?!

Aren't there a number of vulnerabilities with ssh1 and aren't we always encouraged to avoid ssh1 due to this?

Ahhh, got it! Disable ssh2 and ssh1, that way you're totally safe :)

bitch, bitch, bitch

[Erris]

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

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.

Even worse than that

[sjames]

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.