New Vulnerabilities in Portable OpenSSH

Non-standard configuration by grub · 2003-09-23 08:02 · 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" Most moronic submitter comment ever.

--
Trolling is a art,

Re:Non-standard configuration by Frymaster · 2003-09-23 08:10 · Score: 4, Insightful

writers looking for a typewriter-with-memory would be better served by Notepad or the Mac equivalent.
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?

--
2 1337 4 u!
Re:Non-standard configuration by grub · 2003-09-23 08:16 · 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.

--
Trolling is a art,
Re:Non-standard configuration by Oestergaard · 2003-09-23 10:35 · Score: 2, Informative

Unfortunately, privilege separation does not work with with OPIE, the one-time password system.

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 able to log on to from untrusted terminals).

It sucks, but it's the best we have for now, it seems.

I do look forward to finally getting that 2.6 SELinux toy box set up ;)
Re:Non-standard configuration by Oestergaard · 2003-09-23 11:44 · Score: 2, Informative

Interesting.

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

It sounded like it was something that could be fixed fairly easily - I was lazy and didn't bother to try doing that myself, and just went with no privsep to get a working setup. I suppose someone could have fixed whatever the problem was, in the mean time. Or maybe the problem somehow exists on Debian and not on NetBSD - I'm sure there is a reasonable explanation somewhere ;)

Thanks for letting me know. I should check up on it.

hmm by tedtimmons · 2003-09-23 08:03 · Score: 4, Funny

Who is pam, and what did she have to do with openssh?

-ted

Re:hmm by r_j_prahad · 2003-09-23 08:15 · Score: 4, Funny

Pam was my ex-wife. She was pluggable by too many.
Re:hmm by TedCheshireAcad · 2003-09-23 09:17 · Score: 2, Funny

Well, apparently there wasn't much Privilege Separation going on, or you would never have found out.
Re:hmm by un4given · 2003-09-23 10:10 · Score: 2, Funny

Pam was my ex-wife. She was pluggable by too many.

Yes, sorry about that. I discovered an exploit when I inserted a 'long' into a 'short' buffer in PAM's module...

A solution? by gpinzone · 2003-09-23 08:04 · Score: 4, Funny

This vulnerability apparently has to do with PAM, so you can use the 'UsePam no' option in your config file.

Wouldn't that prevent anyone from loging-in? I guess that's a solution. Why not disconnect the network cable, too?

Re:A solution? by Asgard · 2003-09-23 08:07 · Score: 3, Insightful

Disabling PAM would only be a problem if you had only allowed PAM-specific authentication methods.
Re:A solution? by Corgha · 2003-09-23 08:09 · Score: 2, Troll

The PAM support in that version of portable OpenSSH is broken, anyway. They ripped the old PAM support out and replaced it with something half-done.

That's why I backported the security patches, instead of upgrading. Now I'm glad that I did.
Re:A solution? by Corgha · 2003-09-23 14:32 · Score: 2, Interesting

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

Time for a new spin on security practices? by Anonymous Coward · 2003-09-23 08:06 · Score: 4, Funny

Maybe the OSS community needs a Trustworthy Computing initiative =]

Re:Time for a new spin on security practices? by jbottero · 2003-09-23 08:10 · Score: 2

OpenSSH... A Microsoft product, right? Oppss... Forgot, one can not criticize open source on the same standards we hold "M$" to...
Re:Time for a new spin on security practices? by ninewands · 2003-09-23 08:36 · Score: 5, Insightful

OpenSSH... A Microsoft product, right? Oppss... Forgot, one can not criticize open source on the same standards we hold "M$"

Well, yes, we should hold them both to the same standard ... so when Microsoft starts announcing it's own self-discovered vulnerabilities and releasing Day-Zero patches to fix them I will be just as critical of OpenSSH security as I am of Windows *cough*security*cough*.

--
utter rubbish
Re:Time for a new spin on security practices? by Digital+Dharma · 2003-09-23 09:04 · Score: 2, Interesting

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.

--
End of Line.
Re:Time for a new spin on security practices? by ajs · 2003-09-23 09:04 · Score: 2, Insightful

Bravo! I'm glad someone is paying attention to this. Just because we happen to have a community that expects the patch to be available 20 seconds before the first person finds it is no reason to measure Linux and Windows on different yard-sticks. If the OpenSSH team can get a patch to vendors and vendors release a fix within a day or two, then that's what we should expect from Windows. And when Windows doesn't keep to that standard, we should all wonder why.
Re:Time for a new spin on security practices? by evought · 2003-09-23 09:12 · Score: 5, Insightful

Also, notice that this is a problem which *may* be remotely exploitable in a *non-standard configuration*, when certain default security measures have been *disabled by the user*.
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? by tshak · 2003-09-23 10:08 · Score: 2, Insightful

when Microsoft starts announcing it's own self-discovered vulnerabilities and releasing Day-Zero patches to fix them

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.

--

There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
Re:Time for a new spin on security practices? by ComputerSlicer23 · 2003-09-23 11:27 · Score: 2, Interesting

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
Re:Time for a new spin on security practices? by Short+Circuit · 2003-09-23 13:13 · Score: 2, Informative

Sure, dependencies can be an issue. But saying that upgrading and patching *nix platforms does not produce any mind-numbing dependency issues is simply a self delusion.

I used to run Debian Woody (stable). At the cost of not getting the latest features, I got all the stability I could ask for, with all of the security patches backported. Now I run Debian Sid (unstable), which tends to have dependency problems, but I at least have control over them. And if worse comes to worst, I can install the patches personally.

--
tasks(723) drafts(105) languages(484) examples(29106)

PAM is not in by default by Anonymous Coward · 2003-09-23 08:08 · Score: 4, Informative

Before we all panic, note that PAM is not in the default build.

It's also not in slackware builds (thanks Patrick).

Re:PAM is not in by default by volkerdi · 2003-09-23 09:18 · Score: 2, Insightful

Newsflash genius, most people don't use slackware.

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.

Re:I don't understand by SwansonMarpalum · 2003-09-23 08:09 · Score: 3, Informative

Portable OpenSSH refers to OpenSSH running on some system which is not OpenBSD

--
"Give away the stone, let the oceans take and transmutate this cold and faded anchor." - Maynard James Keenan

JEBUS by tempest303 · 2003-09-23 08:10 · Score: 2, Insightful

This is getting ridiculous. Maybe it's time for OpenSSH development to completely halt for the moment, and do some serious auditing? This is just plain sad... I know people have been joking about switching to lsh, but at a current "score" of 3 to 1, I'm starting to consider it, at least for the time being... :-/

--
The Free desktop that Just Works

Re:JEBUS by Kalzus · 2003-09-23 08:17 · Score: 5, Insightful

Arguably, this announcement *is* the result of an increase in code vetting on the part of the portable OpenSSH team. Just a thought.

--
"The Devil does not know a lot because He's the Devil, He knows a lot because he's old." -- unknown
Re:JEBUS by Corgha · 2003-09-23 08:40 · Score: 3, Insightful

On the contrary, arguably, this announcement is the result of 3.7p1 and 3.7.1p1 being rushed out the door with new, unvetted PAM code.

That's why it doesn't affect earlier versions.
Re:JEBUS by Ed+Avis · 2003-09-23 09:04 · Score: 3, Informative

One of the principles behind OpenBSD (and therefore OpenSSH) is full disclosure of security vulnerability. They don't want to lie about how secure the software is or try to conceal things from you. Therefore the vulnerability reports (and fixes) are published as soon as possible. In practice, I think they do wait to have a patched version before announcing the bug.

--
-- Ed Avis ed@membled.com
Re:JEBUS by JoeBuck · 2003-09-23 09:21 · Score: 2, 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:I don't understand by Compenguin · 2003-09-23 08:10 · Score: 4, Informative

From the portable openssh website:
"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 by V.+Mole · 2003-09-23 08:11 · Score: 3, 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.

OpenSSH in RedHat 9 and others by avij · 2003-09-23 08:15 · Score: 5, Informative

The RH-supplied latest OpenSSH (3.5p1-11) doesn't seem to accept the "UsePam no" directive that was suggested as a workaround, so if you go ahead and add that line to your /etc/ssh/sshd_config and say "service sshd restart", SSH will complain about an invalid configuration option and refuse to start. Just for your information..

--

Follow your Euro bills at EBT

Re:OpenSSH in RedHat 9 and others by ZerothAngel · 2003-09-23 08:19 · Score: 3, Informative

Well, the advisory states that "Older versions of portable OpenSSH are not vulnerable." So it's probably not much of a worry anyway.
Re:OpenSSH in RedHat 9 and others by virtual_mps · 2003-09-23 08:22 · Score: 4, Informative

More importantly, the problem only affects OpenSSH 3.7p and 3.7.1p, so adding "UsePam no" to a 3.5p installation is unnecessary.
Re:OpenSSH in RedHat 9 and others by Eric+Seppanen · 2003-09-23 08:25 · Score: 3, Informative

According to Redhat Bugzilla bug 104917, Red Hat has never shipped openssh 3.7, so they're not vulnerable to this. No workaround or fix is needed.

--
314-15-9265

Re:A better solution by sqlrob · 2003-09-23 08:17 · Score: 3, Insightful

More secure?

RedHat boxes are safe by menscher · 2003-09-23 08:19 · Score: 4, Informative

Just to alleviate some of the panic, RedHat boxes are safe.

Re:RedHat boxes are safe by Jhon · 2003-09-23 08:31 · Score: 2, Informative

Is that accurate? I read that as saying "With the version shipped with RH and RH Enterprise" -- which is an OLDER version. Doesn't that mean that if an RH user has updated SSH to a newer version, they are vulnerable?
Re:RedHat boxes are safe by MSG · 2003-09-23 08:37 · Score: 4, Insightful

Please don't post links to bugzilla. Bugzilla is a database driven application, an linking to it directly from slashdot will certainly swamp that system. The information in the bugzill entry is:

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? by Dr.+Bent · 2003-09-23 08:19 · Score: 3, Funny

This vulnerability apparently has to do with PAM

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!

Re:Good Times by satch89450 · 2003-09-23 08:19 · Score: 2, Interesting

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 by TheCRE · 2003-09-23 08:26 · Score: 3, Interesting

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

New Motto by Greyfox · 2003-09-23 08:28 · Score: 4, Funny

15^H^H10 minutes without a remote root exploit!

--

I'm trying to teach myself to set people on fire with my mind... Is it hot in here?

Re:Case matters by avij · 2003-09-23 08:31 · Score: 2, Insightful

Um, no.

man sshd: keywords are case-insensitive and arguments are case-sensitive, meaning that usepam and UsePam and UsePAM are equivalent.

--

Follow your Euro bills at EBT

Yippee! by mrpuffypants · 2003-09-23 08:32 · Score: 4, Funny

oooh! Patching every other day is fun!

This is just like being a MCSE! Now I can hang out with the NT guys and chat about patching!

Re:Yippee! by archen · 2003-09-23 10:26 · Score: 2, Funny

NT guy: "so like... you DON'T reboot? Huh? Patch? HuH? How can you patch and not reboot?"

Re:Apple affected? by bnenning · 2003-09-23 08:34 · Score: 2, Insightful

The vulnerability apparently only affects OpenSSH version 3.7, and Mac OS X uses 3.4, so we should be ok.

--
How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.

Re:Just like MS then. by phliar · 2003-09-23 08:35 · Score: 4, Insightful

With MS, they're gaping holes that we hear about because the worm actually did do the damage. The bugfixes for OpenSSH are all questions about bugs being found by reading the code, and nonstandard installations -- not known compromises. The speed with which security issues are handled is also much better than anything those yahoos ever do.

--
Unlimited growth == Cancer.

fact of life by NumLk · 2003-09-23 08:36 · Score: 4, Insightful

I'm not trying to be a tool here, but seriously, does anyone ever expect any piece of software to be 100% foolproof? Software is complex, and in its complexity lies opportunity for problems to arise. Sometimes they are simple coding mistakes, sometimes they are problems that arise when the software isn't used as its developers envisioned.

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.

--
Children in the backseats don't cause accidents. Accidents in the back seats cause children.

Microsoft are the reason by SnowWolf2003 · 2003-09-23 08:40 · Score: 2, Funny

Are we sure Microsoft aren't involved in this project in some way?

Re:Is the default config file safe? by Ratcrow · 2003-09-23 08:47 · Score: 4, Informative

No!

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.

Not so fast! by MarcQuadra · 2003-09-23 08:47 · Score: 3, Interesting

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?

--
"Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails

Re:Just like MS then. by pmz · 2003-09-23 08:53 · Score: 2, Insightful

I don't see a difference.

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 OpenSSH are much less likely (although no one's perfect) to sweep things under the rug than Microsoft.

Microsoft is like a car dealership complete with greasy salespeople. OpenBSD/OpenSSH basically have no salespeople (word of mouth, who'd have thunk that?).

Which makes you feel more warm and cozy?

--
Healthcare article at Kuro5hin

RPM's for Red Hat 7.2, 7.3 and 8.0 by corz · 2003-09-23 08:56 · Score: 2, Informative

I created these a little earlier today:

http://projects.standblue.net/rpms/openssh/3.7.1p2 /

Enjoy.

Re:RPM's for Red Hat 7.2, 7.3 and 8.0 by Anonymous Coward · 2003-09-23 09:13 · Score: 2, Interesting

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

All the more reason for Microsoft bashing by Dan+Ost · 2003-09-23 08:57 · Score: 2, 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 Microsoft until they start designing their products with
security in mind.

--

*sigh* back to work...

More fixes than PAM by Soft · 2003-09-23 08:59 · Score: 3, Informative

According to the Changelog:

- markus@cvs.openbsd.org 2003/09/18 08:49:45 [deattack.c misc.c session.c ssh-agent.c] more buffer allocation fixes; from Solar Designer; CAN-2003-0682;

it would seem that in addition to the PAM patch, there are more buffer management-related fixes which didn't find their way into 3.7.1p1 but prompted Debian to make a third update to ssh. One may want to update even on OpenBSD or with PAM disabled.

"Patch *again*" == no big deal by psyconaut · 2003-09-23 09:02 · Score: 5, Insightful

The poster seems to insinuate that patching again is a chore...security is, by very nature, a moving target. I'm *glad* they find vulnerabilities and post regular patches...proves to me, at least, that somebody is on-the-ball.

Heck, just be thankful they don't belong to the Microsoft school of security and fixes ;-)

-psy

Re:Just like MS then. by Shdwdrgn · 2003-09-23 09:04 · Score: 3, Insightful

It's different because they advised everyone immediately of the problems, and released a patch as soon as they had one. MS has in the past spent considerable time blaming the customers for problems (for instance, IE automatically downloading and executing exe files from websites, without the user's consent).

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 the MS advocates are spending a lot of time complaining about how everyone here bashes MS. I've been using Windows since 3.1 was released. Now I have a choice. Linux isn't for everyone. It requires a lot of time to learn it. Windows also required a lot of time to learn, but most people don't remember that. Back in the days when GUI's were new, we expected things to be difficult, and we lived with that until it was fixed. Now linux is coming in and trying to do everything the right way, but apparently many people are unwilling to give linux the same chance they originally gave to Windows.

Windows is like a first-draft program. It's a kludge. It works, and with enough effort you can add a lot of eye-candy to make it look like a polished system, but underneath, it's still a kludge. They started with a vague idea of what they were going to write, and created it as best they could.

Linux is more like a second-draft program. It's built from scratch completely based off of all the concepts that were discovered in writing the original version. The goal is in site, the mistakes can mostly be avoided, and they have a clear idea of what they're doing from start to finish. It's still not going to be perfect, but it's built on a solid understanding of what needs to be done.

Up next..? Who knows, but I imagine that comparing the next generation software to what we have now will be like comparing a finely-tuned Indy car to a horseless carriage.

Re:EXCUSE ME!? by reverendslappy · 2003-09-23 09:20 · Score: 2, Insightful

Huh?

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

To repeat a post above... by Paulo · 2003-09-23 09:26 · Score: 2, Informative

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

So, how was this about "ignoring the problem" again?

Use real ssh. by Anonymous Coward · 2003-09-23 09:37 · Score: 2, Insightful

I stopped using OpenSSH last year, These problems were hinted in the massive flaws from last year. Sure everything has flaws, but this is like everyday, for something that we're supposed to trust FOR security. Hell, at this rate, running telnetd is more secure. Its less likely you'll be sniffed then get hit by some passing worm within 5 mins of putting a box online.

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 mention its the offical version of SSH.

OpenSSH == wuftpd/sendmail of security software, get rid of it. At least for now.

You think you're joking but you're not by Skreech · 2003-09-23 10:41 · Score: 2, Funny

Frying an Egg on an Athlon XP

OS X - propably not affected by phooka.de · 2003-09-23 11:19 · Score: 2, Interesting

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 on securityfocus, 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...

Hmm... by Dr+Rick · 2003-09-23 12:02 · Score: 3, Interesting

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

--

Dr. Rick
- "It's such a fine line between clever and stupid" (Nigel Tufnel)
- Zort! (Pinky)

Take "OPEN" out of the name by JavaJoint · 2003-09-23 13:08 · Score: 2, Funny

Ya know, maybe it's time to take the word "Open" out of OpenSSH. It's becoming too much of a self-fulfilling prophecy.

How about "TheSourceIsOpen_ButWeWillBeDamnedIfYouGetInWithou tAPasswordSSH"? ...

Slashdot Mirror

New Vulnerabilities in Portable OpenSSH

67 of 324 comments (clear)