Slashdot Mirror
OpenBSD Local Root Hole Patched
unFKNreal writes "A fellow by the name of Georgi Guninski has discovered a
local root compromise
in OpenBSD 2.8 & 2.9. He says its due to a race in the kernel, similar to the linux kernel race a few months back."
The
patch is out
as of a few hours ago. Even a BSD newbie like me got his firewall patched and rebooted with no problem, after taking a moment to reread the
patching instructions
and
kernel rebuild FAQ.
The bad news: the hole was posted to bugtraq Thursday morning, with exploit code, so the black hats had a jump on you (sadly, note the
date
Guninski says OpenBSD was informed). If your system has any users you don't fully trust, check it over carefully after you patch!
Update 3h later by J : Apparently NetBSD is affected too, and a fix is
in-tree.
well I remember the days when Theo would get his goat on and fix something in under 2 hours. Guess he must be gettin' laid these days. How many months do you think this sploit was "in the wild" before someone decided to report it (or was independantly discovered by a white hat)?
How we know is more important than what we know.
SNIP>>---
--
--
I like to watch.
No, there was another local root compromise a few months ago. Before that, they were claiming 3 years without a remote hole and two years without a local hole. Now they just advertise the time since the last remote hole.
Assuming OpenBSD was informed on 9 June 2001, still 6 days turnaround isn't bad when you compare it to the turnaround on Microsoft patches.
Granted, OSS projects frequently do far better, butremember, there was a time two decades ago when six days turnaround onm a patch would have been unheard-of.
Here's to hopeing that such critical patches are only nessecery infrequently, especialy with BSD which has such and old code-base (read: rich with history).
--CTH
--Got Lists? | Top 95 Star Wars Line
Alright, so the OpenBSD team was informed June 9th, the general public knew of the exploit on June 14th, and the openBSD team patched it on the 15th.
The reason why it took so long is probably 'cause they got Darren Reed to initially inform them of the exploit.........
Feed the need: Digitaladdiction.net
I recently isntall OpenBSD as a router for my home network and its wonderful. The install took less than 30 minutes from a home-brewed CD. It automagically recognized all of my hardware, and was much less painful than some linux installs I've done.
Installing apache was painless (except I had to install libtool first), and NAT, dhcpd, and ipf were pre-installed, all I had to do was enable them.
Note: OpenBSD used to claim 3 years without a remote root exploit and 2 years without a local one, but they dropped the local record a few months ago after one was found, and now the remote root exploit record is up to 4 years.
Mark Duell
This is not the first root compromise on BSD in several years. OpenBSD only assure the system will be secure under the default install, which is rarely if ever used by anyone in production, Hence OpenBSD been succeptible to many of the common format string vulnerabilities, and things like the FTP globbing issue also affected OpenBSD.
Its a good system, but some of the users suck by seeing it as a blanket solution to everything. Same with any OS really.
From what I remember reading recently, isn't this the first root compromise on BSD in several years? I've been considering switching critical components to OpenBSD recently, and to be honest hearing this is reassuring. My hat's off to the guys that found this--as well as the entire BSD teams that put together such good solid code.
Long, cute, or funny Sigs are just another form of over compensation, used by geeks, nerdz, etc.
It's possible the OpenBSD team was more focused on releasing 2.9 which many were waiting for as opposed to hurrying to release a patch, only they know. It's funny how many are quick to jump the gun and criticize them for doing something they've done freely, and nicely for years. It's also possible that it got lost in communication.
The submitter sounds as if someone at OpenBSD just refused to acknowledge a problem which is sort of biased, since he wouldn't know why the patch took some time. Remember the team has a bug reporting system in which many different steps are taken to resolve a problem. Sometimes they have to recreate the problem entirely, and since systems vary, it's also possible someone who did test it, wasn't affected on their machine.
Many reasons can be attributed for not releasing it asap. Seriously though, when incidents are submitted no one corp, or person should be expected to release a fix one minute later.
Want Root?
It's not the first for years, they claim no remote exploits in four years. OpenBSD is still liable to face similar problems under third party software, and admin misconfigurations.
Want Root?
Can't you read... OpenBSD is still liable to face similar problems under third party software, and admin misconfigurations.
Third party as in if you add something from ports and it has issues you're likely going to be affected by this. Which part confused you, and where in your low IQ did you see my post something about third party anything along with kernel?
Want Root?
From the OpenBSD website "Four years without a remote hole in the default install!" Remote hole != local hole
you can't ack before you balls.. you just
Seems to me like some people expect perfection from the OpenBSD crew. Yeah, it's a root exploit, but there's certainly far less exploits for major damage on OpenBSD than any or most any other OS's. I don't understand how someone can complain about a patch coming out 6 days after starting work on it. Knowing what I know about the OpenBSD bunch, I wouldn't be surprised if it took 6 days because they wanted to be sure the patch would totally cover the problem without leaving a hole or causing another hole in the system somewhere. I'm still using OpenBSD as a prefered choice OS. Can't knock the soup or the cook, just because one bowl had a fly in it. BSD still rocks, especially when it's open.
<Dev/>The hardest bugs to spot are the ones that happen rarely. Even harder to spot are exploits...because while they are technically bugs, in practice they generally rely on the author to do things that no sane coder would ever try in a "normal" program.