New Vulnerabilities in Portable OpenSSH

An anonymous reader writes "The OpenSSH team has uncovered multiple exploitable vulnerabilities in the days-old portable release of OpenSSH. That's right folks: time to patch *again*. 3.7.1p2 is now available. Instructions and mirror list here. Please note that this vulnerability only affects *portable* OpenSSH--so if you are running OpenBSD, you're safe. This vulnerability apparently has to do with PAM, so you can use the 'UsePam no' option in your config file. Info on the advisory here and here."

Re:Good Times

[satch89450]

Ahh, the joys of another afternoon spent patching boxes. I guess it is better than waiting for a vendor to come up with a patched binary package.

When I heard there was a second patched version last week, I said to myself that these things come in threes, and that I would wait for "the next round." So much for updating 50 boxes more than once.

Will the third time be the charm, or should I avoid being on the bleeding edge and wait for next week's discoveries?

(At least it isn't like the Microsoft patches, which come at less frequent intervals and usually do more damage to my apps than the protection is worth. -- Obligatory Microsoft Bash)

The Need for Open Source Watchdogs

[TheCRE]

In light of the recent CERT/CC advisories regarding security vulnerabilities in the Sendmail and OpenSSH programs (even before the problems with new release of portable Open SSH) the Center for Regulatory Effectiveness' WatchDog Watch discussed the need for open source watchdogs. Please see, www.thecre.com/wdw/20030922_open_source.html Winston Security Director, WatchDog Watch

Not so fast!

[MarcQuadra]

Not so fast!

The LAST vulnerabilities were for 3.6 and 3.7 as well, but 3.4 COULD be vulnerable as it's now 'off the beaten path' and these vulnerabilities seem to have been discovered in a code audit triggered by the recent attention given to OpenSSH. Apple had to patch their 3.4 version, and I'd expect another minor software update package from Apple in the next few days to address this.

Anybody out there know if it's easy to build current versions (3.7.1p2, etc.) of OpenSSH on OS X with the developer tools installed, or is there some very compelling reason Apple is sticking to 3.4 and just adding to it?

Re:Time for a new spin on security practices?

[Digital Dharma]

Actually, I thought they did. In all the big press cases in the last couple of years a patch has always been available for quite some time before the exploit became public. Think Code Red, Slammer, Blaster, etc. Microsoft does keep it's code pretty solid and secure. Unfortunately there are a lot of paper MCSEs and other unqualified people proclaiming to be administrators out there who wouldn't know how to secure a system if BillG was standing in the room with them telling them how to do it. Microsoft gets a bad rap because of this, but I think there will come a time when all of the OSS communities' huffing and puffing about how insecure MS is and how secure their distro of UberNix 12.x is will eventually come back to bite them in the ass. Business Development departments do pay attention to this sort of stuff, and if they ever get the sense that MS and *nix are pretty much on even ground (which they are. I've played with both for years and I can't really see any differences) They'll opt for MS every time because it's familiar and proven. All bias remarks aside, it really is.

Re:RPM's for Red Hat 7.2, 7.3 and 8.0

[Anonymous Coward]

Erm, those OSes aren't vulnerable. See the RH Bugzilla page on it -- they're too old to be vulnerable to this.

Appreciate the work, but there's no need :)

OS X - propably not affected

[phooka.de]

For those out there wondering - after the latest update to 10.2.8, ssh showsthis version:

OpenSSH_3.4p1+CAN-2003-0693, SSH protocols 1.5/2.0, OpenSSL 0x0090609f

In the advisory [securityfocus.com] on securityfocus [securityfocus.com], it says that the affected versions are "Portable OpenSSH versions 3.7p1 and 3.7.1p1" - so it seems that since it's not using the latest, hottest implementation, OS X is not affected.

Of course, I'm only guessing here...

Re:Time for a new spin on security practices?

[ComputerSlicer23]

Not to burst your bubble or anything, but I'm willing to bet the time differential between when the Copyright owner of the code knows about the problem, and when the patch is released, is much larger with Microsoft then with Open Source. There are several well documented cases where Microsoft sat on their hands rather then fix a known bug, so people finally started going public with them. That's when Microsoft started fixing them. They now attempt to have people keep quiet about them, until after they release a patch. That's a whole different thing then when the holes are annouced to the public.

On the last OpenBSD issue, I think the total time between the issue being told the the guys at OpenSSH, and the fix coming out, was measured in single digit number of hours. I can be reasonably sure that doesn't happen at Microsoft.

Finally, in my experince, on a RedHat Linux machine, there is almost nothing I've upgraded in the last 3 years that was a security fix. Never, not a single one, in applying every update that RedHat has put out for 3 years for 6.2, 7.0, 7.1, 7.2, 7.3, 8.0, 9.0. I can't recall the number of people I knew who didn't apply Security Packs for NT 4.0 because they fundamentally broke other critical pieces of software (Anything past NT4.0 SP1, broke the version of Netscape Server a former employer used to use, so they never did upgrade any of the fixes past SP1 for the longest time). That's because security fixes, only fix the security problem. A lot of MS patches fix a dozen security problems, and then add a lot of functionality. That's really nice to make the compact and all. I wasn't ever a big user of individual hot fixes, which might have gotten me to work around this issue.

Now upgrading to get new functionality has screwed up a couple of machines. However, assuming you can reboot the machine, there is almost nothing that has given me problems when upgrading a RedHat machine. I know that I had trouble with a couple of PAM modules not getting reset, but that was because I wasn't trying hard enough to restart the services (they held onto the shared libraries that we're insecure, and I didn't restart them all). It's not that they didn't work, they just were not secure until I re-booted the machine.

Most of the truely horrific dependencies I've heard of out of UNIX upgrades come from SUN, most of those it's my understanding, that they essentially, are upgraded inplace, while running. That's not something a sane person tries to do. However, SUN hardware and software is special. They do a pretty good job, but the dependencies are tricky (even more so when there are patches that once installed, can never be uninstalled).

The vulnerablity going public, and the worms that exploit them months after the patches are a reflection of the users and admins of the machines, not of the software writers themselves. You can find numskulls who run RedHat or Windows with ease. My guess is that as a percentage more numskulls run Windows then RedHat, but I think that's because Windows users/admins are a significantly larger group. To run RedHat isn't done by the average home users. If RedHat shipped by default on as many machines, that statement would flip flop, and RedHat would have a higher percentage of clueless users.

Kirby

Hmm...

[Dr Rick]

Doesn't it seem strange that the finding of multiple bugs in the same piece of open source software in a short period of time is stated as a strength of open source while the same thing in Microsoft software is stated as a weakness... Yes, in the open source case they were found by code inspection and in the case of Microsoft they were found by exploit, but a patch a day is still a patch a day. It's not always a good idea to rush patches out as soon as a potential hole is found...

Re:A solution?

[Corgha]

Well, I haven't had time to trace it down entirely, nor will I in the near future, but it doesn't surprise me that those modules would work fine, as one is a session module and the other is, I think, an interactive one.

However, you used to be able to use PAM for plain-old password authentication with authmethod password, and they seem to have just ripped support for that out in auth-passwd.c.

Now, I may have sort of a weird setup, but when things worked in all the previous versions, something stops working suddenly in a new version, and you see that they re-wrote that part of the code, well, it's not too much of a leap to think that the re-write introduced some problems.

Nor does it seem like FUD when that re-write demonstrably introduced another flaw (the subject of this /. story).