OpenBSD Local Root Hole Patched 39
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.
panic on the streets of london (Score:1)
still, it's cause for concern, especially on a system with a large number of users, or any system where you don't trust the users. among the arguments i heard on the openbsd mailing lists was that this exploit wasn't especially cause for concern because 1) the exploit requires things that use rfork() and nothing in the default install does, and 2) local users can already DoS and other f*** up the local system if they're determined enough, so this isn't an especially high priority exploit....
these are both weak arguments, IMHO, (and the first is just mistaken) but these also weren't the opinions of any of the core developers AFAIK, just some of the other folks on the list. what i found more interesting was to hear the sentiment that the bug would get fixed insofar as it gave one of the developers an itch--which sounds perfectly normal and exactly right for any free, open source project, but it sure *sounds* alarming to hear that a root exploit will get fixed when someone feels like getting to it--even if it is the case that the patch will (and did) get released faster than most patches to any commercial products.
all in all, i'm still pleased as punch about openbsd and i think it's as much a testament to openbsd's success that a local root exploit raises so much concern *just because* of the high expectations we have come to have for it.
Re:waiter I have a fly in my soup. (Score:1)
Re:6 day patch turnaround... Try that Microsoft (Score:2)
Isn't there a BSD section on /.? (Score:1)
6 days? (Score:1)
- grunby
Re:waiter I have a fly in my soup. (Score:3)
SNIP>>---
--
Re:Still impressive (Score:2)
you missed the point. (Score:1)
it's still a very worthwhile OS, and we really shouldn't be complaining about it's few stumbles.
<Dev/>Who knew... (Score:1)
Poor guy. He's just got no luck with computers.
FreeBSD also (Score:1)
Since we are regurgitating bugtraq posts: although Guninski's exploit did not work on FreeBSD, the same race issue that was used in his exploit was purportedly found in several places in the FreeBSD code. Due to the somewhat generic nature of the issue, I suspect this may appear in more unix-type OSs as well.
Re:Weren't the audits supposed to take care of thi (Score:1)
And the article specifically says that it's a race, not a buffer overrun. But I guess reading can be hard, even if you're so l33t that finding all the exploitable bugs in an operating system is as easy as cooking ramen noodles.
Here's a dime... go buy some realistic expectations.
6 day patch turnaround... Try that Microsoft (Score:2)
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
Re:Weren't the audits supposed to take care of thi (Score:1)
Not impossible in an absolute sense, but merely extremely difficult. It is possible (though unlikely) that someone will come up with some process for quickly proving the correctness of code or that a very large number of mathematicians banging at a very large number of whiteboards would prove OpenBSD (or any other piece of software) correct.
Yes, but my understanding is that this is neither a memcpy or buffer length check but rather a race condition, which is something completely different.
OK: You're crazy. Well, maybe not crazy but certainly overzealously assuming foul play despite absence of any evidence. If "this exploit should have easily been found", then why didn't you find it? The answer is that security is a very complicated thing and that even well-intentioned, talented people occasionally make mistakes.
--
They had several reported to them on June 2nd (Score:1)
Re:waiter I have a fly in my soup. (Score:1)
Seems to me like some people expect perfection from the OpenBSD crew
=
Have you ever seen any of Theo's posts in bugtraq?
maru
I know why it too them so long....... (Score:2)
The reason why it took so long is probably 'cause they got Darren Reed to initially inform them of the exploit.........
Re:Still impressive (Score:3)
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
Re:Weren't the audits supposed to take care of thi (Score:1)
- It's true that it is mathematically impossible to ensure that a piece of fairly complex piece of code is bug-free...
No, it's actually impossible.Not impossible in an absolute sense, but merely extremely difficult.
There is no way of proving that a program terminates on a given input (in the general case), let alone that it is correct.
Proving correctness in respect to some specification can also be impossible (undecidable) in certain cases.
(Of course there is more to it than this, but I can't be asked to explain it all right now...)
Re:correction (Score:1)
Re:Still impressive (Score:1)
Re:``four years without a remote hole in the defau (Score:1)
Local and remote are not the same. Hence the different names.
Re:Weren't the audits supposed to take care of thi (Score:1)
int main () { return 0; }
You shouldn't have too much trouble proving that
this program terminates on any input.
Re:Still impressive (Score:1)
--
Re:Dammit! (Score:1)
Notthe first root compromise. (Score:2)
Its a good system, but some of the users suck by seeing it as a blanket solution to everything. Same with any OS really.
Still impressive (Score:3)
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.
sigh (Score:3)
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.
9 June 2001 (Score:1)
umm (Score:1)
Dammit! (Score:1)
correction (Score:2)
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.
poor troller (Score:2)
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?
Re:Weren't the audits supposed to take care of thi (Score:1)
These types of vulnerabilities are never cookie-cutter, and cannot be fixed by the usual "grep for scary syscalls" routine.
Vulnerabilities like this will probably never go away
sedawkgrep
a local compromise not remote (Score:2)
waiter I have a fly in my soup. (Score:4)
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 [www.bsdtod...mtargetbsd] still rocks, especially when it's open.
<Dev/>Re:Weren't the audits supposed to take care of thi (Score:5)
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.
Um....'REMOTE' (Score:1)
Re:Who knew... (Score:1)
I was thinking the same thing... if this guy starts on the unix-type OSs with the same fervor that he has demonstrated on MS systems over the last year, things could get interesting (and way more secure). This guy is an exploit whirlwind.
maru
Re:6 day patch turnaround... Try that Microsoft (Score:2)
OpenBSD also tests their patches rigorously to make sure that they dont cause more problems *cough*Microsoft*cough*
Mark Duell