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?"
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.
Exploiting a daemon running as root is going to yield root privileges, it doesn't matter if root is allowed to log in through that daemon or not. You're talking about two different concepts here.
Is your browser retarded?
OpenBSD 3.1-release (straight install from the CD) is vulnerable, however OpenBSD 3.1-current (the latest code) has been running with privsep enabled for almost 2 months.
/ ssh/sshd_config?rev=1.52&content-type=text/x-cvswe b-markup
http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin
The -stable branch of OpenBSD (release + critical bug fixes) was patched to run with privsep enabled a month ago and is also ok (if you made sure to update). I don't really care wether or not this break their security streak. My OpenBSD boxes have been running fine for some time now and any user that simply followed the -stable branch isn't affected by this.
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..)
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.
Yeah, but it depends if the nature of the exploit is one that yields execution privileges (such as corrupting the user stack and running your own code before sshd drops down from root), or is a protocol weakness which then allows you to (for example) bypass authentication and log in, which would give you user privileges (assuming root logins are disabled).
"It's overkill, of course. But you can never have too much overkill." - Anonymous Slashdot Coward
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.
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.
Slagborr
its not hard when they disable practically all the networkservices on it. its easy to defend a house with no doors and no windows. openbsd still rox though
here is what debian has to say:
http://www.debian.org/security/2002/dsa-134
it looks like they have priv sep on by default