Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
BSD Operating Systems

OpenBSD Local Root Hole Patched 39

Posted by jamie from the could-have-been-worse dept.
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.
This discussion has been archived. No new comments can be posted.

OpenBSD Local Root Hole Patched More

OpenBSD Local Root Hole Patched

Comments Filter:
  • 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)?
  • Why isn't this in the BSD section of /. [slashdot.org]?
  • George Guninski regularly finds and releases exploits for many different services/os's. Whenever I see his name on Bugtraq [securityfocus.com], I know it's gonna be a crazy day. According to Rain Forest Puppy's policy [wiretrip.net], 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
  • Here is an example of one of Theo's posts:

    SNIP>>---

    To: bugtraq@security-focus.com
    From: freegaysex@openbsd.org

    On 9 June 2001, someone whined:

    > and then I found the hole. It was a
    >> remarkably easy exploit, actually, and I now
    >> wonder just how thorough the "code audit"
    >> was. Perhaps Theo should take a more open stance
    >> and let more people into the development
    >> process. Hey, fuck you buddy! I don't want scum like you NEAR my software! Mine! In fact the next release will query my personal server and automatically wipe your disk if it detects your email or IP. Man, I am so going to go outside and break bottle against trees in my anger! Oooh!

    Theo "The Rat" de Raadt


    --

  • Re:Still impressive (Score:2)

    by Anonymous Coward
    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.

  • 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.
  • but at least one ought to be able to ensure that it is exploit-free! Memory copies and buffer length checks are not the hardest thing in the world to find.

    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

  • It's true that it is mathematically impossible to ensure that a piece of fairly complex piece of code is bug-free...

    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.

    Memory copies and buffer length checks are not the hardest thing in the world to find. You would think that a full audit would have uncovered them all.

    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.

    Call me crazy, but this is the paranoid world in which we live. Nothing can be taken for granted anymore. This exploit should have easily been found. The fact that it wasn't suggests foul play.

    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.


    --
    // mlc, user 16290
  • 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.........

  • Re:Still impressive (Score:3)

    by mduell ( 72367 ) on Friday June 15, 2001 @04:15PM (#147811)
    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...

      • Not impossible in an absolute sense, but merely extremely difficult.

    No, it's actually impossible.
    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.
  • 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.
  • 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.
  • Does it have native support for RAM yet?

    --

  • 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.

  • Still impressive (Score:3)

    by clark625 ( 308380 ) <clark625 AT yahoo DOT com> on Friday June 15, 2001 @03:31PM (#147820) Homepage

    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)

    by joq ( 63625 ) on Friday June 15, 2001 @03:34PM (#147821) Homepage Journal

    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.
  • Alex, When was OpenBSD informed?

  • umm (Score:1)

    by asland ( 26316 )
    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!


  • 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.

  • 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?
  • 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
  • From the OpenBSD website "Four years without a remote hole in the default install!" Remote hole != local hole

  • waiter I have a fly in my soup. (Score:4)

    by ThatField ( 201302 ) on Friday June 15, 2001 @03:53PM (#147829)

    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/>
  • If you had ever coded even simple reentrant code you would realize how subtle race conditions can be. And look at the conditions required for the exploit to work:

    Works best after reboot - the +s program must not be executed before, seems
    executes /tmp/sh
    /tmp/su must be a link to +s program
    if the +s program has been executed, create and run shell script the size of RAM
    You may need to type "fg" if the program receives stop signal
    you may need to run the program several times
    Even allowing for all of this, the exploit doesn't work every time.

    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'.


  • 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
  • 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.

    OpenBSD also tests their patches rigorously to make sure that they dont cause more problems *cough*Microsoft*cough*

    Mark Duell

Slashdot Top Deals

The world will end in 5 minutes. Please log out.

Close