New Vulnerabilities in Portable OpenSSH 324
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."
Non-standard configuration (Score:5, Informative)
From the article: At least one of these bugs is remotely exploitable (under a non-standard configuration, with privsep disabled)
Priviledge Separation saves the day again. I think this is a testament to the forward thinking of the OpenBSD and OpenSSH people: they know that human error introduces potentially exploitable bugs, hence the work that went into PrivSep to minimize the risk.
"The lengths some people will goto to try and damage Theo's pride" [slashdot.org] Most moronic submitter comment ever.
Re:Non-standard configuration (Score:2, Redundant)
Re:Non-standard configuration (Score:5, Insightful)
your belt may fail
your suspenders may fail
if you're really serious about keeping your pants up, use both!
this is the theory of theo-n-the-openbsd-cats. you used priv sep plus all the other security goodies.
you don't say that doing nightly backups is a "weak" practice because the backups could fail at the same time as your main drive. do you?
Re:Non-standard configuration (Score:2)
sure my ass might flash sometime but we all know how easy it is to disable annoying flash ads.
Re:Non-standard configuration (Score:2)
But if you're really, really serious you'll take care that your hips don't disappear.
Hard for some hackers, I know, but worth it in the pants security field.
If you're a kilt sort of guy all bets are off though, seeing as they lack any sort of basic security to begin with.
KFG
Re:Non-standard configuration (Score:5, Insightful)
Having a small amount of the sshd code running as root with the 'sshd' user handling the rest helps make it harder for other exploits. I don't think anyone would suggest that PrivSep makes an exploit impossible, but it is another great layer on the security-onion.
Re:Non-standard configuration (Score:3, Informative)
So either you run privsep, or you run OTP.
Without OTP, you'd be crazy to log on to your ssh box from anything but a trusted terminal (e.g. your office workstation or your personal laptop). Without OTP, you cannot log on from a net cafe or anything like that, if you're just slightly security concious.
So I'm stuck with privsep and no OTP on some machines, and OTP without privsep on another (which I need to be abl
Re:Non-standard configuration (Score:3, Informative)
Is that using PAM?
My box is on Debian 3.0 - the explanation I saw at that time was that the combination of PAM and the extra OPIE password query wouldn't work with privsep because of some too simplified assumptions in SSH/privsep about what would be asked by the system and what would be submitted by the user.
Or something like that. I set it up half a year ago and to be honest I don't remember the details - I just remember that at that time OPIE+privsep was a no-go, at least on a Debian box wi
hmm (Score:5, Funny)
-ted
Re:hmm (Score:5, Funny)
Re:hmm (Score:3, Funny)
Re:hmm (Score:3, Funny)
Yes, sorry about that. I discovered an exploit when I inserted a 'long' into a 'short' buffer in PAM's module...
A solution? (Score:5, Funny)
Wouldn't that prevent anyone from loging-in? I guess that's a solution. Why not disconnect the network cable, too?
Re:A solution? (Score:4, Insightful)
Re:A solution? (Score:2)
Re:A solution? (Score:3, Troll)
That's why I backported the security patches, instead of upgrading. Now I'm glad that I did.
Time for a new spin on security practices? (Score:4, Funny)
Re:Time for a new spin on security practices? (Score:2)
Re:Time for a new spin on security practices? (Score:5, Insightful)
Well, yes, we should hold them both to the same standard
Re:Time for a new spin on security practices? (Score:2, Interesting)
Re:Time for a new spin on security practices? (Score:5, Insightful)
This is not in the same league as "Oops, we left the RPC port open and rootable by default."
The class of errors being fixed by OpenSSH is very different and the design takes security much more seriously.
Re:Time for a new spin on security practices? (Score:3, Insightful)
Re:Time for a new spin on security practices? (Score:3, Insightful)
They will once the OSS community start providing 0-day enterprise quality patches that actually get regression tested before being installed on mission critical servers. MS may have a few poorly tested patches in its relatively distant history, but MS still puts its patches through far more testing than most OSS patches are put through when released. Testing takes time, period.
Re:Time for a new spin on security practices? (Score:3, Interesting)
PAM is not in by default (Score:4, Informative)
It's also not in slackware builds (thanks Patrick).
Re:PAM is not in by default (Score:2)
Re:PAM is not in by default (Score:3, Insightful)
Most people use Windows.
In addition not having pam normally is not something to be proud of!
No, normally it is. A quick glace through the BugTraq archives will show how often there are vulnerabilities having something to do with PAM. By comparision, sendmail looks mighty bug free.
JEBUS (Score:2, Insightful)
Re:JEBUS (Score:5, Insightful)
Re:JEBUS (Score:2)
Maybe there is no answer, I don't know. At least they get the patches out quickly.
Re:JEBUS (Score:3, Informative)
Re:JEBUS (Score:4, Insightful)
That's why it doesn't affect earlier versions.
Re:JEBUS (Score:3, Insightful)
No, the vulnerabilities are due to new code in 3.7; the Red Hat and Debian people who backported only the security fixes to older OpenSSH versions are safe. They are not old vulnerabilities that were discovered by an increase in code vetting.
Re:JEBUS (Score:2)
Why? Do you know of a tool that provides more milage than OpenSSH while providing pretty darn good security?
Pretty darn good is all we should ask for, anyway, because near-perfect security requires network isolation and those MAC things people bitch about so much.
Re:JEBUS (Score:2)
OpenSSH in RedHat 9 and others (Score:5, Informative)
Re:OpenSSH in RedHat 9 and others (Score:3, Informative)
Re:OpenSSH in RedHat 9 and others (Score:2)
Re:OpenSSH in RedHat 9 and others (Score:5, Informative)
Re:OpenSSH in RedHat 9 and others (Score:4, Informative)
Re:OpenSSH in RedHat 9 and others (Score:2)
And thus, an effective workaround.
Re:Case matters (Score:3, Insightful)
man sshd: keywords are case-insensitive and arguments are case-sensitive, meaning that usepam and UsePam and UsePAM are equivalent.
Re:Case matters (Score:2)
Uhm, no.
Change ANY option in your sshd_config from 'yes' to 'Yes' or 'no' to 'No' and try to restart the sshd daemon. It WILL fail. It is absolutely, positively case-sensitive. The manpage is wrong, not the code.
Re:Case matters (Score:2)
Re:Case matters (Score:2)
Please try to understand, before one of us dies!
RedHat boxes are safe (Score:5, Informative)
Re:RedHat boxes are safe (Score:2, Informative)
Re:RedHat boxes are safe (Score:2)
Re:RedHat boxes are safe (Score:5, Insightful)
Opened by mjc@redhat.com (Mark J Cox, Security Response Team Lead) on 2003-09-23 11:16
http://www.openssh.com/txt/sshpam.adv came out on Sep23 with two new
vulnerabilities that affect OpenSSH.
Both these issues only affect OpenSSH 3.7 and 3.7.1. Red Hat Linux and Red Hat
Enterprise Linux are not vulnerable to these issues as we ship with earlier
versions (with the addition of backported security fixes for other issues).
Keeping this bug open for a few days to enable users searching bugzilla to find
out that they are not vulnerable.
When will it end? (Score:3, Funny)
When will people learn that non-stick cooking spray causes more harm than good? Unneeded fat, calories and remote root exploits are just some of the problems caused by these unsavory products. For god's sake, people...there are better ways to dissipate heat and prevent sticking and burning. For one, turn that CPU clock speed down! Just because you can fry an egg on your motherboard, doesn't mean you should! That's what the CD-ROM drive is for!
You think you're joking but you're not (Score:3, Funny)
Not the way to compete with MS (Score:2, Funny)
On second thought, maybe more patches will make IT managers think that OSS=MS in quality and will begin to use OSS more because it is as good as MS.
NarratorDan
Apple affected? (Score:2)
Re:Apple affected? (Score:3, Insightful)
Not so fast! (Score:4, Interesting)
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?
The Need for Open Source Watchdogs (Score:3, Interesting)
Is the default config file safe? (Score:2)
# Set this to 'yes' to enable PAM authentication (via challenge-response)
# and session processing. Depending on your PAM configuration, this may
# bypass the setting of 'PasswordAuthentication'
#UsePAM yes
If you have to uncomment out that line to enable PAM authentication, then *not* uncommenting it is equivalent to setting it to "no" (like the advisory says to do) yes? The advisory
Re:Is the default config file safe? (Score:2)
*Ahem*, I meant, of course:
Re:Is the default config file safe? (Score:5, Informative)
From the top of sshd_config:
"The strategy used for options in the default sshd_config shipped with OpenSSH is to specify options with their default value where possible, but leave them commented. Uncommented options change a default value."
In other words, simply uncommenting the line changes nothing -- the default is shown commented. For the SRPMS of OpenSSH-3.7p1, UsePAM is set to Yes.
Depends, but generally -NO- (Score:2)
Re:Is the default config file safe? (Score:2)
[wince]...
Thanks
p.s. - works fine with
UsePAM no
[whew]
New Motto (Score:5, Funny)
Inefficient! (Score:2, Offtopic)
15^H0 minutes without a remote root exploit!
... oh, wait. You were doing that for illustratory purposes...
I reeealy need to get a life...
Yippee! (Score:5, Funny)
This is just like being a MCSE! Now I can hang out with the NT guys and chat about patching!
Re:Yippee! (Score:2)
Fun?
# apt-get upgrade
# exit
Boring. The way it should be.
Re:Yippee! (Score:2)
Wait. Shouldn't this be:
Without the update step, apt wouldn't know about the new packages.
Although, I suppose you could have the apt-get update step in a cron job.
fact of life (Score:4, Insightful)
As users of software though, it is irresponsible to assume that just because it is commercial, open source, MS, non-MS, or whoever is the messiah of the day's product that it will never have unexpected problems. Admittedly, some companies software appears to be worse than others, but that is the gamble we take when we build complex systems.
Microsoft are the reason (Score:2, Funny)
Problem building openssh 3.7.1p2 (Score:2)
I got p1 to work ok on Mandrake 8.1 system.
The new version apparently will not allow for keyboard-int authorization. I configured --with-pam and I don't have PAM off in my
I could not even get 3.7.1p1 to compile on an older mandrake box.. Doh. gotta upgrade.
Oh PAM! (Score:2)
Matt Fahrenbacher
RPM's for Red Hat 7.2, 7.3 and 8.0 (Score:2, Informative)
http://projects.standblue.net/rpms/openssh/3.7.1p2 / [standblue.net]
Enjoy.
Re:RPM's for Red Hat 7.2, 7.3 and 8.0 (Score:2, Interesting)
Appreciate the work, but there's no need
More fixes than PAM (Score:4, Informative)
"Patch *again*" == no big deal (Score:5, Insightful)
Heck, just be thankful they don't belong to the Microsoft school of security and fixes
-psy
OpenBSD (Score:2)
I've heard statements like these again and again, and every time I thank the decision I made to use OpenBSD on our firewalls. Their focus on security really does pay dividends. Yes, they still get it wrong from time to time. But they're far ahead of the rest of the field.
Mirrors? (Score:2)
Use real ssh. (Score:2, Insightful)
ssh from ssh.fi is more secure out of the box (no ssh1), requires alot less depedencies on other programs, and is more configurable. Not to men
Here comes another Mac OS Update (Score:2)
damn.
At least we know a patch will come about quick.
It's bloated and... (Score:2)
OpenSSH has grown a little too big to be maintained properly.
Okay, mod me down again...
Hmm... (Score:3, Interesting)
Re:I don't understand (Score:3, Informative)
Re:I don't understand (Score:5, Informative)
"Normal OpenSSH development produces a very small, secure, and easy to maintain version for the OpenBSD project. The OpenSSH Portability Team takes that pure version and adds portability code so that OpenSSH can run on many other operating systems (Unfortunately, in particular since OpenSSH does authentication, it runs into a *lot* of differences between Unix operating systems)."
Re:I don't understand (Score:4, Informative)
OpenSSH is OpenBSD specific. "Portable SSH" is what everybody else uses. In other words, the OpenBSD developers (quite reasonably) don't spend any effort making SSH portable off of OpenBSD, and sometimes use OpenBSD specific functions. Other people then spend the time/effort to make run on Linux, etc. There are features (such as, presumably, PAM support) that are not in the core OpenBSD version.
Re:A better solution (Score:4, Insightful)
Re:Good Times (Score:3, Interesting)
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,
Re:Just like MS then. (Score:5, Insightful)
Re:Just like MS then. (Score:2)
No, they're not. For instance, Blaster was announced and patched for months.
Face it people, there really isn't a difference when it comes to software insecurity. Nothing is foolproof, and this just gives people some egg on their face.
Re:Just like MS then. (Score:2)
Re:Just like MS then. (Score:2)
The difference is that the OpenSSH people found the problem themselves and announced the fix with the problem. While the MS people do this, they usually wait until there's egg all over their face. The MS people also have a few billion more dollars to work with. You can buy a lot of code auditing with a few billion dollars. Well, you or I could. MS has other priorities.
Re:Just like MS then. (Score:2)
As long as humans are doing the coding
...and the configuring, installing, maintaining and testing of patches.
So pick your poison:
Microsoft: "Windows is soooo e-z to use, any monkey can run a server!" (Collects cash from awe-struck boss.) Later, shit hits fan.
BSD: "Only leet h4Xor5 should edit config files and if they can't figure out what the hell to do from reading 50 man pages, the RFCs and the source code, then they should keep their sorry asses away from systems that are run by real men."
There's
Re:Just like MS then. (Score:3, Insightful)
1) The people behind OpenBSD and OpenSSH are much less driven by time-to-market and ooh-shiney crap than the monkeys at Microsoft are.
2) OpenBSD and OpenSSH actually strive for simplicity rather than obsess over bullet-points.
3) OpenBSD's default install has basically only OpenSSH as a public service (among a handful more). This is already light-years ahead of numerous (thousands undiscovered, probably) default-available remote-root exploits in Windows.
4) The people behind Ope
Re:Just like MS then. (Score:3, Insightful)
It's different because this is only one of a handful of programs which have required security updates in the past X weeks. How many security updates has MS released in the same amount of time?
All of
Re:Just like MS then. (Score:2)
OSS code is not appreciably less buggy than closed code when it is written; it becomes more secure as bugs get fixed that wouldn't have been found if it weren't open. Here w
EXCUSE ME!? (Score:2)
With Microsoft, we wouldn't know of days after the virus makes the news.
This is a prime example of why OSS is beter. It has been fixed before those "evil hacker terrorist communists" find out about it.
Re:EXCUSE ME!? (Score:2, Insightful)
Nimda:
Patch Released: August 15, 2001
Major Exploit Starts: September 18, 2001
SQL Slammer Worm:
Patch Released: July 24, 2002
Major Exploit Starts: January 25, 2003
MS Blaster Worm:
Patch Released: July 16, 2003
Patch Released: August 11, 2003
Re:Time for less windows bashing? (Score:2)
Windows bugs get press when a couple of guys write a worm that infects millions of machines worldwide and causes global internet slowdowns and billions of dollars in economic damages.
So why, exactly, should we be lenient?
All the more reason for Microsoft bashing (Score:3, Offtopic)
Microsoft could learn something from this. The OpenSSH team finds a problem,
announces it, and makes a fix available. Then they identify similar problems,
announce them, and make fixes available.
Microsoft seems to follow one of three different procedures depending on
circumstances:
1. ignore the problem until there's an exploit and public outcry
2. quietly release a fix and then advertise it when there's an exploit and
public outcry
3. leave the problem unfixed in order to force people to upgrade
I say we bash Mi
To repeat a post above... (Score:2, Informative)
Patch Released: August 15, 2001
Major Exploit Starts: September 18, 2001
SQL Slammer Worm:
Patch Released: July 24, 2002
Major Exploit Starts: January 25, 2003
MS Blaster Worm:
Patch Released: July 16, 2003
Patch Released: August 11, 2003
So, how was this about "ignoring the problem" again?
That's how this was caught (Score:2)
Re:Patch available for Gentoo already (Score:2)
emerge sync && emerge -uU openssh && /etc/init.d/sshd restart would be shorter and would do what you want.