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.
so, #1, it's a local, not remote root exploit.
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.
No...people don't expect perfection, the OpenBSD guys/users consider themselves perfect. Just ask any of them, or look at their message postings. There's a real attitude problem.
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.
Why isn't this in the BSD section of /.?
George Guninski regularly finds and releases exploits for many different services/os's. Whenever I see his name on Bugtraq, I know it's gonna be a crazy day. According to Rain Forest Puppy's policy, the waiting time is just a _suggestion_, not a law. I'd personally wait, and release the exploit announcement along with a vendor supplied patch (thus being RFP compliant), but that's just me.
- grunby
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.
it's still a very worthwhile OS, and we really shouldn't be complaining about it's few stumbles.
<Dev/>...Georgi broke anything but Microsoft systems?
Poor guy. He's just got no luck with computers.
Easy does it!
This comment has been submitted already, 276865 hours , 59 minutes ago. No need to try again.
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.
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.
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
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.
--
Just look at what Al Viro (Yes -- him) found: http://www.securityfocus.com/templates/archive.pik e?mid=188474&threads=0&list=1&end=2001-06-02&fromt hread=0&start=2001-05-27&
=
Seems to me like some people expect perfection from the OpenBSD crew
=
Have you ever seen any of Theo's posts in bugtraq?
maru
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
- 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...)
The no root exploit claim only stands for out of the box installs before any third party software or user configurations have been done.
man
No manual entry for
Shift+Page UP/Page Down will allow you to view the stuff you missed, BTW.
Keyword: "remote"
Local and remote are not the same. Hence the different names.
An interesting anagram of "BANACH TARSKI" is "BANACH TARSKI BANACH TARSKI"
This is obiously untrue. Consider this:
int main () { return 0; }
You shouldn't have too much trouble proving that
this program terminates on any input.
--
--
I like to watch.
or, you could just not put any local users on your firewall and not be affected by it at all.
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?
Alex, When was OpenBSD informed?
I really doubt that there are only 7000 OpenBSD users.
And I was just bragging to my co-workers how secure my firewall was after their Win based firewall was just compromised. I'm gonna catch a bunch of crap on Monday! The patch IS amazingly easy to apply though. Good thing most OpenBSD users are cluefull enough to WANT and KNOW how to apply them!
.sig wanted: Must be concise, funny, and display my cleverness.
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?
Truthfully, logic errors like this one are the toughest to ferret out during an audit. The code can be 100% secure syntactically/semantically, but logically flawed.
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
Is that a salami in my pants or am I just happy to be me?
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.
Actually this is an exploit that would be executed 'locally'. Still a potentially damaging exploit, but you had to let the user's on first, then they could '0wN j00'.