Slashdot Mirror
Slashback: OpenSSH, Bio, Timeliness
Things that make you want to bring back thumbscrews. A few days ago, we mentioned the release of OpenSSH 3.3; compared to previous versions, the biggest change in 3.3 is increased emphasis on privilege separation. Today, Theo de Raadt sent word of an OpenSSH vulnerability being worked on by ISS and the OpenBSD team, details of which are expected to be published early next week.
In an announcement sent to bugtraq, he wrote: "However, I can say that when OpenSSH's sshd(8) is running with priv separation, the bug cannot be exploited.
OpenSSH 3.3p was released a few days ago, with various improvements but in particular, it significantly improves the Linux and Solaris support for priv sep. However, it is not yet perfect. Compression is disabled on some systems, and the many varieties of PAM are causing major headaches.
However, everyone should update to OpenSSH 3.3 immediately, and enable priv separation in their ssh daemons, by setting this in your /etc/ssh/sshd_config file:
UsePrivilegeSeparation yes
Depending on what your system is, privsep may break some ssh functionality. However, with privsep turned on, you are immune from at least one remote hole. Understand?
3.3 does not contain a fix for this upcoming bug.
If priv separation does not work on your operating system, you need to work with your vendor so that we get patches to make it work on your system. Our developers are swamped enough without trying to support the myriad of PAM and other issues which exist in various systems. You must call on your vendors to help us."
Theo emphasizes the role of vendor cooperation in making privilege separation work on the full range of systems on which OpenSSH runs. "If the vendors don't start pulling their part," he says in an email, "by the time the bug is posted their customers will be left unprotected. These vendors who do not do the right job and instead just 'sell sell sell' are starting to become annoying. On a lot of systems today, privsep does NOT work well at all. The vendors have not been helping!"
A patched version of OpenSSH could be released as soon as Friday, incorporating vendor patches received by this Thursday.
Read More on Stallman. Vamphyri writes: "Sam Williams, author of 'Free as in Freedom', biography of GNU/Linux founder Richard M. Stallman has gone live with the online free version 1.0 of FAIFzilla.org. The paper pulp version publishers O'Reilly & Associates agreed under the terms of the GNU Free Document License and have their own version up at their site. Williams' site allows for content and corrections to be submitted by readers. He hopes for contributions to be included in later editions of the O'Reilly bio. Also: CGI coders wanted for site enhancement, paragraph and line numbering, searches etc. Maybe a CVS Tree is in order? :)"
"Urpmi Norton" doesn't work for some reason. MrResistor writes "Upon logging in to my computer at work this morning, I was greeted by a virus update notice from McAfee SecurityCenter. The update for today includes W97M/Melissa@MM, and of course McAfees newly manuf^H^H^H^H^Hdiscovered threat, the W32/Perrun JPEG virus (which was also highlighted in yesterdays update). All of the updates in the last week or so have been rated Low or No Threat (except for Perrun, which is "Low On Watch". It seems that in addition to manufacturing new threats, they're also rehashing old threats to keep subscription renewals up. Perhaps it's time for Slashdot to add an Ethics topic?"
News.com did an interview with CmdrTaco.
Ethics topic? I thought we had "The Almighty Buck" topic to take care of those pesky ethics...
---
I post links to stuff here
Since sshd is enabled by default in OpenBSD 3.1 (OpenSSH 3.1), and privilege separation isn't enabled by default, doesn't that mean OpenBSD 3.1 has a remote root hole?
With the recient Interview with the CEO of UnitedLinux and the following discussion of giving back to the community you can see how important this is. How many systems use SSH? Every single one of mine. This is where a UL can really shine, but helping OpenSSH in the shape of work towards a patch. This helps provide security to the distos and gives back the community for people who run smiliar setups.
This really shouldn't stop with SSH though. Distros in general should be helping out large development projects like this.
~Travis
I don't think I need or want Slashdot to tell me what is or isn't ethical.
To many, total abstinence is easier than perfect moderation. -- St. Augustine
I installed OpenSSH to *gain* security, not to lose it. Bad.
can it be true?
and does not redirect to goatse.
Hollow words will burn and hollow men will burn.
Again, OpenSSH has another remote exploit! It is climbing my list of insecure software on my machine, which is pretty scary. Can't someone write secure software??
I suggest we start calling Theo not by his full name, but by his initials. It's becoming quite clear that he's just as loony as [ESR|RMS].
Urrrgh... how many times does this get discussed?!?! So what? OpenBSD is still far more secure than most Linux distros or Windows. The only O/S I've ever come across with better security than OpenBSD is OS/400 by IBM.
"Hi, there's a remote exploit in sshd. Upgrade to our new! even better! version of sshd. (Fine print: it also has the hole, but covers up the symptoms). We won't tell you what the problem is, unless you're a big distributor."
Replace "distributor" by "OEM", and this might be a M$ bulletin.
Isn't this a shameless plug to make people upgrade to a new version of sshd (too new to have established a security record yet)? Isn't this discrimination of people who roll their own system?
I understand this behaviour is prefectly rightful, but it's sign of an attitude that certainly pisses me off. What does the "Open" in "OpenSSH" stand for, anyway?
UsePrivilegeSeparation yes
Read the rest of the config. READ, DAMMIT.
For linux users, you guys are outta luck. Contact your vendor for an rpm. Or, install the source to openssh by hand, and solve all the damn pam errors. We can cover you guys for a few days, so firewall behind a buddy with freebsd until you get this all rpm-happy.
Good luck.
"How many others don't find the time for all these updates?"
What's so time consuming about 'apt-get update; apt-get upgrade'? Oh, wait...
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
After reading that post about OpenSSH, I
really do not understand how anyone could find
this guy difficult to work with.
UsePrivilegeSeparation Specifies whether sshd separates privileges by creating an unprivileged child process to deal with incoming network traffic. After successful authentication, another process will be created that has the privilege of the authenticated user. The goal of privilege separation is to prevent privilege escalation by con taining any corruption within the unprivileged processes. The default is ``yes''.
Since it defaults to yes (on Debian at least) I don't think we have too much to fear.
I used to be a loyal Norton AV user for years, until they started with this "subscription" bullshit. I've been using McAfee ever since. $29 retail at Wal*Mart isn't that bad, and plus I get free updates every Wednesday sans subscription. It even runs an auto-update service so I don't even have to worry about updating... it takes care of itself! It even ships with other cool features like a monitor for Outlook (it checks for trends in messages... e.g., if I try to send a message with more than a couple of recipients in the To: field, HAWK halts the process and asks if I really want to send that e-mail. Annoying, yes, but at least I feel protected. That on top of Outlook's I-won't-let-anything-access-the-address-book feature (you can enable address book access for a minute or 5 at a time, if you wish, for things like Palm sync to access the addr book). What I deal. Peter Norton is a sellout. If I had a copy of Norton AV today, I'd wipe my ass with the CD, no matter how painful that may be!
;)
On another note... First the Apache hole, now this OpenSSH exploit? Looks like some folks are joining the ranks of Windows server users
Aw, fuck it. Let's go bowling. - The Big Lebowski
This could be flamebait, but it should be said.
..
Consider this, would you rather use an Operating System, where the community just shrugs off the frequently once a week remote holes with simply, "go grab the updates"
.. or an Operating System where the community is surprised and in disbelief that a remote hole was found after 5 years which causes entire community to start bitch fights over the right to claim its the most secure Operating System still, despite the fact the remote hole was found by the Operating System developers, and fixed before it has actually been exploited.
You don't have to be Stephen Wolfram to figure this one out.
..There's a-dooin's a-transpirin'
Does passing through a firewall work even when the operating system doing the firewalling is dead?
Before one goes and accuses McAfee of manufactoring viruses, I suggest the authors provide solid evidence and proof that they actually did this. Becuase if one wants to accuse anyone of unprofessional conduct, it would only be ethical to proceed in this order. First proof, then accuse. Got that?
The upside is that they do tend to produce useful things, or have a salutary effect on those around them. So unless you disagree with what they do, you should simply dismiss their personal peccadilloes as the price you pay for having someone devote the majority of their brainpower to a single issue, and do useful work on your (and everyone else's) behalf.
Time to take a lesson from the PHB playbook - the natural response to an email like Theo's goes something like "Yeah, yeah, Theo, nice work. Keep it up. Oh, and have it done by the end of the week, willya?"
Q: "Where do Linux Experts go when they need Windows Hosting ?"
A: A mental institution.
Thank you very much for reading, and a sweet good-night to all.
graspee
No... Can't Be!
For fucks sake... you people are always "oh we have bug fixes in 24 hours... Fsck you M$ *uNF* *uNF* *uNF*" and now you have to use a WORKAROUND that may not work on everyone's systems and it's the VENDOR'S fault that SSH wants to use some specific feature that *THEY* think every vendor should have.
I'm sorry. It doesn't work like that. Fucking fix it the first time or don't release stuff you KNOW has security exploits in it. It's plain fucking irresponsible to do it.
RedHat has an OpenSSH errata security fix from 5/22 HERE. Anyone know if this is the bug in question?
-Pete
Soccer Goal Plans
funny how this didn't make it into the main article:
We've been trying to warn vendors about 3.3 and the need for privsep,
but they really have not heeded our call for assistance. They have
basically ignored us. Some, like Alan Cox, even went further stating
that privsep was not being worked on because "Nobody provided any info
which proves the problem, and many people dont trust you theo" and
suggested I "might be feeding everyone a trojan" (I think I'll publish
that letter -- it is just so funny). HP's representative was
downright rude, but that is OK because Compaq is retiring him. Except
for Solar Designer, I think none of them has helped the OpenSSH
portable developers make privsep work better on their systems.
Apparently Solar Designer is the only person who understands the need
for this stuff.
apt-get update
apt-get dist-upgrade
That fixes everything.
From: Theo de Raadt [deraadt@cvs.openbsd.org]
/etc/ssh/sshd_config file:
Subject: 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.
OpenSSH 3.3p was released a few days ago, with various improvements but in particular, it significantly improves the Linux and Solaris support for priv sep. However, it is not yet perfect. Compression is disabled on some systems, and the many varieties of PAM are causing major headaches.
However, everyone should update to OpenSSH 3.3 immediately, and enable priv seperation in their ssh daemons, by setting this in your
UsePrivilegeSeparation yes
Depending on what your system is, privsep may break some ssh functionality. However, with privsep turned on, you are immune from at least one remote hole. Understand?
3.3 does not contain a fix for this upcoming bug.
If priv seperation does not work on your operating system, you need to work with your vendor so that we get patches to make it work on your system. Our developers are swamped enough without trying to support the myriad of PAM and other issues which exist in various systems. You must call on your vendors to help us.
Basically, OpenSSH sshd(8) is something like 27000 lines of code. A lot of that runs as root. But when UsePrivilegeSeparation is enabled, the daemon splits into two parts. A part containing about 2500 lines of code remains as root, and the rest of the code is shoved into a chroot-jail without any privs. This makes the daemon less vulnerable to attack.
We've been trying to warn vendors about 3.3 and the need for privsep, but they really have not heeded our call for assistance. They have basically ignored us. Some, like Alan Cox, even went further stating that privsep was not being worked on because "Nobody provided any info which proves the problem, and many people dont trust you theo" and suggested I "might be feeding everyone a trojan" (I think I'll publish that letter -- it is just so funny). HP's representative was downright rude, but that is OK because Compaq is retiring him. Except for Solar Designer, I think none of them has helped the OpenSSH portable developers make privsep work better on their systems. Apparently Solar Designer is the only person who understands the need for this stuff.
So, if vendors would JUMP and get it working better, and send us patches IMMEDIATELY, we can perhaps make a 3.3.1p release on Friday which supports these systems better. So send patches by Thursday night please. Then on Tuesday or Wednesday the complete bug report with patches (and exploits soon after I am sure) will hit BUGTRAQ.
Let me repeat: even if the bug exists in a privsep'd sshd, it is not exploitable. Clearly we cannot yet publish what the bug is, or provide anyone with the real patch, but we can try to get maximum deployement of privsep, and therefore make it hurt less when the problem is published.
So please push your vendor to get us maximally working privsep patches as soon as possible!
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).
Customers can judge their vendors by how they respond to this issue.
OpenBSD and NetBSD users should also update to OpenSSH 3.3 right away. On OpenBSD privsep works flawlessly, and I have reports that is also true on NetBSD. All other systems appear to have minor or major weaknesses when this code is running.
(securityfocus postmaster; please post this through immediately, since i have bcc'd over 30 other places..)
LSH (http://www.net.lut.ac.uk/psst/)
I love SSH. It's been installed on my boxen (regardless of OS) since it was stable enough to kill off telnet.
My problem with both the announcement as well as the patch is thus.
1. Theo nor any of the posters I've seen are willing to tell us what the hell is broken. Only that we must upgrade. That just don't cut it, I won't blindly patch without an idea of what is broken. The Debian security release summed it up best.
"Theo de Raadt announced that the OpenBSD team is working with ISS
on a remote exploit for OpenSSH (a free implementation of the
Secure SHell protocol). They are refusing to provide any details on
the vulnerability but instead are advising everyone to upgrade to
the latest release, version 3.3.
This version was released 3 days ago and introduced a new feature
to reduce the effect of exploits in the network handling code
called privilege separation. Unfortunately this release has a few
known problems: compression does not work on all operating systems
since the code relies on specific mmap features, and the PAM
support has not been completed. There may be other problems as
well."
2. Sudden, lack of belief in Full disclosure. Am I the only guy who remembers the days before full disclosure? The OpenBSD Security policy ( http://www.openbsd.org/security.html ) is pretty point blank (to quote)
"we believe in full disclosure of security problems. In the operating system arena, we were probably the first to embrace the concept. Many vendors, even of free software, still try to hide issues from their users"
I think posting a "fix" (ok, workaround) and not telling anyone *why* they should use it is "try[ing] to hide issues from their users"
I'll be firing up R.A.T.S and checking out LSH ( http://www.net.lut.ac.uk/psst/ ) (GNU'd SSH2ish) for my needs from here own out.
and yes, this needs a rant tag and yes I know the OSSH and OBSD teams are seperate, but they share enough philosophy and team members that I gather they have the same opinion on security.
Bugs Bunny was right.
replying to yourself is always a bad thing, but here goes...
if you cut through the bullshit (theo certainly has an interesting way of putting things), what he's saying is this:
there's a hole in sshd. we are working on a patch. if we release it now, you are all f'd, because all your systems will be compromised before you have time to patch them. we are giving you the next week to update your sshd, so that you are no longer vulnerable when we publish the bug+patch. yes, the new sshd has the bug, but is not vulnerable to it. if we fixed it now, the black hats will diff the results and be able to develop a compromise, and you still won't have a patch. oh yeah, we need your vendors' help so that you're all safe by next week.
make sense?
I'm not sure about this, but on the security focus mailing lists there has been discussion about the default installed apache's can be remote root'ed on openbsd due to a bug in memcpy's asm implementation / apache.
Have they ported apt to Solaris?
So much to do, so little bandwidth.
--
Try Mozilla
There is a GNU SSH2-server! It is called lsh and is most probably not vulnerable!
31159 mmap2(NULL, 65536, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS, -1, 0)
= -1 ENOSYS (Function not implemented)
I would definitely call this a problem - MAP_ANON is the culprit. A quick spin through Google Groups shows that they've been talking about this for awhile on the OpenSSH dev list.
It works fine on a 2.4 box.
I think that other poster who recommended heading towards another ssh daemon had the right idea.
There is a /usr/ports movement on debian. Try it is is better. make. make install.
Comparing it to Windows will be a moot point, since El Dorado is going to have a 40% larger code base than XP.
Oh, wait...
So much to do, so little bandwidth.
--
Try Mozilla
So, I'm currently packing my bags and driving to Canada so I can track down Theo and fistfuck him until he feels like an 8th grade girl.
Man this shit pisses me off. Let's introduce a new half broken version of software with a new feature that we didn't ask for and that requires adding users and crap like that.
Jesus, if OpenBSD is the way to be I might rather run Windows. I hope that fuck gets murdered over this. I'm not supposed to worry about my ssh security!!!!!
OpenBSD exists just to make us paranoid, 'cause they fuck up often enough that if they weren't paranoid it'd be 3 days without an asshole in the default install.
Down with the voices! Down with Theo!
So, is this another incompletely researched, uniformative exploit report? Where's the "patch that fixes nothing" for the exploit? Isn't that how ISS does business?
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next.
"Read it; you might need to pass the word on to your vendor, too."
If you need to pass the word on to your vendor you need a new vendor.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
Oh it is SO hard to compile a tarball. PAM errors? Eh, don't have a single PAM file installed, NSS works perfectly fine. Not everyone is a cluebert and relies on packaging. Some people actually know how to solve problems on their own without relying on someone else to set up a package or...port.
Oh, I forgot to mention, I don't need any freebsd box to protect me. My Linux firewall and everything else internally has been running 3.3 since it came out.
Compiling is easy. ./configure w/ options, make, make install, browse configurations.. restart sshd.
-d
Yes the first Apache chunked encoding exploit released by Gobbles was targeted at OpenBSD. Grants you remote access but not root. To get root you still have to run a local kernel exploit. But Apache is not enabled by default in OpenBSD.
There has to be a more mature approach to vulnerability disclosure. We can't always just disclose a serious vulnerability without a fix available in place, especially if it involves a large number of systems.
I think Theo and the OpenSSH team are being responsible, and it shows that they've grown up. The right approach should be to disclose to the appropriate parties first, get a fix done QUICK, and then followed by a full disclosure.
Full disclosure at the premature time is naive and only leads to wide-scale insecurity, NOT security.
It's part of the subject line, see?
Well I just spent a few hours upgrading a handful of openssh installs and firewalling about a dozen others. This is weird though, is there NO other information about this hole except that it's "fixed" by 3.3?
If I have ssh blocked in /etc/hosts.allow, does that stop the bug? If I have AllowRootLogin off, does that stop the bug? Is it SSH protocol 1 or 2? Can this affect existing SSH connections? Is there any other work-around?????
I think we just saw TWO irresponsible announcements in the Open Source world, and I hope it's not a trend.
(SSH is one piece of software I do not like upgrading remotely..)
PS: I haven't gotten his message from Bugtraq yet. In fact I've only gotten 2 messages from Bugtraq today...weird...
yeah, those updates surely are scams! there's no possibility that they could be updates to the signatures to reduce false positives or false negatives, or to improve run speed or anything. after all, we all know that the first version of every piece of software can only be described as 'absolute perfection'.
mY COick iST ILL bigger THAN YOURS so UCKs on ITKNOW!!!!
"Perhaps it's time for Slashdot to add an Ethics topic?"
I'd appreciate it. I'd submit an article on some of the moderations I've recieved lately. Heh.
"Derp de derp."
Please, don't bug your vendor about this unless they don't provide a fix in a reasonable time. Any decent vendor is *already* working on a fix for this, and "passing the word on" a million times is just going to be annoying to their poor support folks.
An important skill for anyone who uses UNIX, *BSD, or Linux is being able to build and install software from source. If you haven't done it before, take some time to learn how to do it properly. It's easier than you might think, just download the source and read the README and INSTALL files.
That's kind of why all the source is released -- you really don't have to wait for packages from your vendor. The packages make future uninstall simpler, true, but sometimes you don't have the luxury of time.
or even - emerge rsync;emerge -u openssh (gentoo)
--- bidz @ efnet/openprojects
Here's the scary message I get in the system log
.rhosts etc. stuff off.
/usr/local/libexec/sftp-server
on my linux machine.
Jun 25 12:40:54 emu sshd[4872]: Accepted hostbased for userblah from 123.12.123.12 port 2654
Hostbased?
But I've got all the hostbased stuff turned off.
A bit of testing shows that _probably_ it is really using RSA or DSA publickey.
But it is very scary indeed to see this (probably wrong) message in the system log.
Does anyone know if this is _definitely_ an erroneous message.
I've got all of my
Here's my sshd_config file:
Protocol 2
IgnoreRhosts yes
PermitRootLogin no
RhostsAuthentication no
RhostsRSAAuthentication no
AllowUsers blah1 blah2
PasswordAuthentication no
PermitEmptyPasswords no
X11Forwarding yes
Subsystem sftp
Be absolutely certain (*especially* when installing 3.3 remotely) that you have created an sshd user, sshd group, and /var/empty directory prior to invoking OpenSSH 3.3. These requirements must be satisfied even if you do not intend to utilize the privilege separation feature. The daemon fails to start without them.
:))
(Disclaimer: This may be blatantly obvious to you, but I'm only attempting to help.
Do you like German cars?
Hey, guess what? That select stuff is NEVER USED in the ftpd. It's part of some new code I'm working on.
There's no way that an unchecked return code for malloc is exploitable, even if I was calling it. What the hell is up with "strictly unwarranted pointer-to-int cast"? This is for x86 linux only, it has no pretense of portability. It's vital that I work with integers, because I am interfacing SML with C (SML treats them as 32-bit words). If you think you have a better way, let me know.
You obviously don't know what you're talking about... Come on.
Have a project no one wants to work on? Need help? Easy. Release a email stating that all previous versions are vulernerable to a root exploit unless your feature X is implemented. Sit back and watch the code roll in.
T
once the exploit has been confirmed and a patch release the full exploit will be posted for all to see.
If you are using the tcp wrappers support built in to OpenSSH, will it be exploitable by ips that are currently already blocked? Or could it only come from allowed ips?
I'm fearing the upgrade, but since I only allow ssh access from certain machines (who also only allow ssh from certain machines), should I assume I am safe until a version of OpenSSH comes out that actually fixes the problem instead of just covering it up?
Bitching about moderations may not be flamebait, but it sure as hell is offtopic! Mod the parent down! ... For that matter, mod this one down, too! :P
I hope you don't let ISS write the patch! ;-)
Prevent email address forgery. Publish SPF records for y
Leaving the OS Wars aside (I run Linux, yes, but I also run FreeBSD, and I would run OpenBSD if they would just get unanal about bootable iso's): Okay, swell. 3.3 has a hole.
How far BACK does this hole extend? Does my 3.1 have it? Does EVERY copy of OpenSSH since the dawn of time have it? Can someone make this clear to me? Is it only versions that have privledge separation? Where is the boundary of this bug?
A patched version of OpenSSH could be released as soon as Friday, incorporating vendor patches received by this Thursday.
Now, why can't MS and the like be that fast? With gazillions of coders on hand, you'd think they'd be able to at least match that. I like how open source projects allow lots of people to work on a problem independantly, all at the same time. The ultimate parallel processing!
It seems that in addition to manufacturing new threats, they're also rehashing old threats to keep subscription renewals up. Perhaps it's time for Slashdot to add an Ethics topic?
Well, MF has been known blow virus threats way out of proportion, almost to the extent of completely making them up, as is highlighted in this article. And there are probably many other examples of bad ethics. But perhaps a Business topic would be more inclusive? Maybe that's covered by The Almighty Buck, but TAB doesn't seem to fit with ethics as well. Would people stand for replacing TAB with Business, or should an Ethics topic be created, or should we just forget the whole thing?
Never underestimate the power of human stupidity.
Anyway. My guess is that this hole is something substantial, possibly very plateform dependent and any patches aren't going to be trivial. Seeing as all you people who felt the need to use fsck in their posts more than once know about as I do about this then my assumptions are as good as yours (and I don't feel the need to use the word fsck as an expletive once). Non-trivial patches mean that commercial vendors are going to take for ever to release final patches and if you are running anything open to the internet then it's likely to be ssh. Add it all up it means this could be very bad.
Now the OpenSSH team is actually two. One that develops new stuff and does code audits specifically for OpenBSD and another that takes that and ports it to other architectures.
All those bitching about full disclosure, you manage to be completely committed to a cause, idiots and miss the point of full disclosure all at once. If the bug is bad then releasing it when only the OpenBSD version of OpenSSH is patched would be an absolute security nightmare. Giving vendors advance notice is very much required in this case. When the vulnerability is announced then I'm sure it will be fully disclosed which will provide the opportunity to test a system for vulnerabilities.
As for you people who are saying Theo is being pro-OpenBSD, read the above paragraph again and answer this question. If Theo really wanted to really rip on other OS's then what could he have done with this announcement? Only OpenBSD not vulnerable and with mindless full disclosure to cover his arse. You do the maths.
The fact is Theo is a complete arsehole when it comes to security. Some see this as not a bad thing. With OpenBSD security is pretty much everything. To the vast majority of other "vendors" security is something they also do and with this Theo has a legitimate gripe. He has got a shitty reception from other vendors to something that will make a vital link in the security chain more secure. Is he making a point of this? Probably. Is he right to do that? Depends on your point of view. If it gets the "vendors" off their arses and add support for priviledge seperation in their ports then would this be considered a good thing? Most definately.
When it boils down to it, Theo would be well within his rights to patch the OpenBSD version of OpenSSH (by using priviledge seperation) and hanging the other vendors out to dry. He didn't. Deal with it.
Nerd: Derogatory term typically directed at anybody with a lower Slashdot ID than you.
Here's the advisory with instructions...
The ftp sites in France are usually updated the quickest.
"Karma can only be portioned out by the cosmos." -Homer Simpson
I know, that's true. But then what does insightfull mean? Or interesting? If you don't agree something is interesting then why should it be? If you don't think it's insightfull (and you actually think it's real bullshit) how can you leave it like that?
It's very difficult to walk the thin line between:
Ok, i don't agree or find it usefull, but maybe someone else does so i don't metamod
Mh, it's full of crap (or trivial)
Anyway, i guess modding up and only ridicule cases down is what's best (for me)...
unfinished: (adj.)
I think I'm going to go back to telnet and s/key! When was the last time you heard of a security hole in telnet?
-russ
Don't piss off The Angry Economist
... is it?!
When you are finished fixing up your tinfoil hat, you can read the diffs to see exactly what has changed.
Yes. According to the openssh bugtrack (http://bugzilla.mindrot.org/show_bug.cgi?id=284) this is a bug and it should be solved in newer versions of openssh
Hasn't anyone honed in on the fact that this so called JPEG virus could potentially be a new and dangerous variant? JPEGs and other associated non executable files are not a threat unto themselves, but based on the brief viral description, they serve as a 'harmless' vehicle for transmitting viral code to be executed by what can be described as a 'bootstrap' executable. How else do you expect to get by the web and email scanners which either filter or STOP any executables from getting through?
Manufactured or not, its a concept which could do some serious damage.
Feed the need: Digitaladdiction.net
If you're using woody - debian testing - add this to your /etc/apt/sources.list:
deb http://security.debian.org woody/updates main contrib non-free
then the usual apt-get update; apt-get upgrade.
The privilege separation code in OpenSSH 3.3 does not work with 2.2 Linux kernels.
It relies on mmap() semantics that aren't supported before kernel 2.4 (maybe 2.3.x). OpenSSH will configure, compile, and install successfully. It will start up, but it will NOT accept connections.
Your clients will get a "broken pipe" message, your syslog will get an "mmap: invalid parameter" message.
The solutions are:
I didn't see this anywhere until I dug into my syslog and then the OpenSSH mailing list. You have been warned.
If you do have kernel 2.4, you should read README.privsep in the openssh source distro, since you need to create a special directory and user/group for this (which also bit me in the butt...even if sshd had worked on 2.2, when I restarted it remotely, it didn't come back up because it didn't have that user...yeah, yeah, rtfm.
Good luck to everyone.
--ryan.
Don't say, "don't quote me," because if no one quotes you, you probably haven't said a thing worth saying.
I'm wondering how you can tell if UsePrivilegeSeparation is working? I have everything installed under Debian 2.2 (had to set UseCompression no). I thought that the subprocesses would be owned by the user 'sshd', but they still are owned by root. Since I went to all this trouble to upgrade, I'd like the peace of mind that if an exploit happens, the intruder won't get any farther than /var/empty as the user 'sshd'.
Slagborr
fix, compile and run new deamon on another port (maybe 23 since your not using it anyway)
ssh in on fixed port, diable old one, and run another instance on the real ssh port.
ssh in on 22 and kill the old deamon, fix your firewall rules, your done.
You really need to find a way to widen mozilla, man. These days, you're an amusing sideshow rather than an annoyance.
Disgard the foul language, and this is actually the most insightful post of the entire thread.
Shame about the language. The points raised, even if only 30% true, should be addressed.
So exactly how is this possible? the windows ssh clients are just now getting to 2.0 (unless you buy the expensive ones) and i found only one ssh client that does the port redirect to make vnc work well.
this is fine and dandy, but until work either switches to all linux workstations or the writers of the windows clients get there, I will not be changing
- Make sure you have installed the new version. /var/run/sshd.pid,
- Make sure the daemon has been killed and restarted.
Note that you can kill a running sshd without hosing the
existing sessions, just be careful you don't close them
all.
- Kill the right one, it lives a pid in
usually.
- Log in through ssh again.
- do a ps -augxww|grep sshd. If you notice some sshd
that don't run as root, then you have privsep.
Had been kind of expecting something like this to happen for a while. ssh (mostly openssh) is becoming a worthwhile target for hacking because it is so widespread, and people are becoming dependent on it. The right answer is to reengineer things so that remote logins are not necessary in so many situations. Even network switches come with ssh now.
potato has a much older, probably unaffected version of ssh.
I'm wondering how you can tell if UsePrivilegeSeparation is working?
Login via ssh, and run:
ps waux | grep sshd
You should see two sshd processes, one with the UID of 0 (root), and the one you are logged in via which should have your UID and "[priv]" in its command name.
If it's not like that, then try restarting sshd. On a RedHat machine run:
Don't know what the init scripts look like on Debian, but you could always kill sshd manually and start it again.
Also make sure you're picking up the configuration files from the right place. They moved from /etc/ to /etc/ssh/ in a recent version.
Thanks for mentioning the new location of the ssh conf files. I upgraded two OpenBSD systems this morning. An old box running 2.7 and a recently upgraded system running 3.1 On the 3.1 box I had the new sshd_config in the wrong place.
Listing the [priv] tag does work. The new ssh sessions show [priv}, but ssh sessions started before I did the upgrade still have the old process record.
One thing they should point out in the upgrade instructions is that you have to kill all existing sshd processes to be certain that the defect is no longer running.
When my host, pair.com, upgraded their sshd after the last vulnerability, they left some old ssh sessions running since before the patch. I had a two week old ssh session which they killed. But others had a one week old session that was left running.
I upgrade OpenSSH remotely all the time. No problem. It's perfectly designed to allow this.
There is a controlling instance of sshd which accepts new connections. Each new connection spawns a new sshd process to handle that connection.
To do the upgrade you only need to replace the controlling sshd process. Once you do this, your *new* connections will run the new code, but your existing session is not affected.
Just be careful not to log out of your upgrade session until you are sure that the new sshd is accepting inbound.
I think announcement made a good call on risk/reward. The fix they suggest doesn't give away anything at all to the black hats, yet it makes it possible for many of us, with a little bit of trouble, to eliminate this vulnerability immediately.
I pay for premium support from RedHat for my servers and at this time there is no RPM for Openssh3.3 My question is should I keep my sshd disabled until they come out with one, or should I suck it up and install it manually? If I suck it up, I don't think I will be renewing our contract next year. What's the point?
Go get the RPMs here ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable / rpm/RH73/
/etc/ssh/sshd_config to uncomment the "UsePrivilegeSeparation yes" line.
I tested this on 3 stock RH 7.3 boxes as well as a RH 7.2 box running 2.4.17 kernel. All still work. Make sure you go into
Actually, just to clear things up, it's
/etc/rc.d/init.d/ will work, /etc/init.d/ should as well in later versions. /etc/init.d/ is the LSB location of init scripts.
/etc/init.d/sshd restart
on later versions of Red Hat machines. While
On a Debian machine, it's
/etc/init.d/ssh restart
(which kindof annoys me... it should be sshd restart, not ssh).
Do you have
deb http://security.debian.org/ woody/updates main
in your /etc/apt/sources.list?
GROGGS: alive and well and living in
I just installed ssh 3.3p1-0.0woody1
There is no
There is no ssh group in
There is no documentation of priv sep in man sshd
There is no UsePrivSep options in the
The ps auwx | grep ssh does not show [priv] in new sshd process instances. My OpenBSD instance does show this.
I _suspect_ that the woody ssh 3.3 was compiled with priv sep disabled, which means it doesn't fix this problem.
*Sigh* I've now tried both the official OpenSSH RPMs and rebuilt ones, and I can't get privelege separation working on any Red Hat 7.x box I have.
Presumably this is what Theo was referring to when saying that priv separation wouldn't work on some platforms.
Anyone manage to get priv sep working on a Red Hat 7.x box? If so, how?
Okay, thanks for the info. Strangely enough, I don't see that "[priv]" is my ps even when I do a ps auwwx|grep sshd, but I do see that there are two processes for each connection, one owned by the user who logged.
Good info, thanks.
I read, I read. Here are my results on 4.2-STABLE after all that reading:
/var/log/messages
sshd: no modules loaded for `sshd' service
sshd: fatal: PAM session setup failed[6]: Permission denied
This happens on every connection, even connections to localhost.
I positively did everything I sshd. What next?
I looked again more closely. With the new ssh when you make a connection, two new sshd processes are created: one running as root, the other running under your userid. And there is also the master instance running as root which spawns new connections.
> I upgrade OpenSSH remotely all the time. No problem. It's perfectly designed to allow this.
Designs are one thing, implementations are another. There have been many reports of folks who've had PAM-related troubles due to installing not-quite-there 3.3p updates.
Nice.. I wish I had read that first, instead of spending 2h messing with this problem.
Thx you!