OpenBSD Journal

y Patch 006: i386 local DoS

Contributed by jose on from the ibcs-compat-overflow dept.

Patch 006 for i386 has been released. This is a local exploit and has been fixed in 3.3 and 3.4. From security.html :
It may be possible for a local user to overrun the stack in compat_ibcs2(8). ProPolice catches this, turning a potential privilege escalation into a denial of service. iBCS2 emulation does not need to be enabled via sysctl(8) for this to happen.
For 3.3, Patch 011 for i386 has been released to address the problem. Note that there is no ProPolice in the kernel on i386 for the 3.3 release, so it can be used to escalate privileges there. An exploit has been openly circulated, by the way.

Thanks to everyone who worked on this patch.

(Comments are closed)

Comments

  1. By gwyllion () on

    A working exploit can be found at http://www.guninski.com/msuxobsd2.html and one by noir at http://marc.theaimsgroup.com/?l=full-disclosure&m=106912070807352&q=p3

  2. By gwyllion () on

    ftp://ftp.openbsd.org/pub/OpenBSD/patches/3.4/i386/006_ibcs2.patch instead of ftp://ftp.openbsd.org/pub/OpenBSD/patches/3.4/i386/006_icbs2.patch

    Comments

    1. By jose () on http://monkey.org/~jose/

      oops .. thanks. fixed the link .. my firebird snapshot isn't letting me cut and paste, so i had to type it by hand ... and typod it in a bunch of places.

      that or i have some form of dyslexia.

      thanks though ... fixed.

  3. By Anonymous Coward () on

    look at the date on that exploit boys...your SECURE OpenBSD boxes have been vuln for almost a year to this bug. Stop lying and calling it a DoS. I've owned tons of OpenBSD boxes in a single command with noir's exploit.

    Comments

    1. By Anonymous Coward () on

      I didn't realise that computers were now measured in tonnage, as opposed to individual units.

      Comments

      1. By Anonymous Coward () on

        How's that working out for you? Being clever, that is.

      2. By Anonymous Coward () on

        Unless he's rooting VAX machines ;-)

    2. By Anonymous Coward () on

      Ummmm, never mind the whole year thing, but I don't see how you've "owned tons of OpenBSD boxes" since it is a local exploit (as far as I can tell), so unless you already had access to the machines, this would do you no good.

      Oh yeah, congrats on being able to type one command that was written by some other guy. You are my new super-1337-ichiban-h@x0r#1-idol now.

      Comments

      1. By Anonymous Coward () on

        ROFLMFAO!

  4. By Deluxe () on

    is is it only in the kernel where there is no propolice?

    Comments

    1. By Anonymous Coward () on

      I believe that there is no propolice in i386 3.3 at all, whereas in i386 3.4 there is propolice and this isn't as much of an issue.

      Comments

      1. By Wouter () on

        Well, your box actually *does* crash if you run it.

        Comments

        1. By Anonymous Coward () on

          Yeah, but my point was that at least the Bad Guy wouldn't have root on 3.4 boxes. small victory, but still much better than being compromised.

          Comments

          1. By Anthony () on

            Agreed... but an OpenBSD local DoS gets about as much press as a remote root would on Linux.

            It could be because of the "BSD is dying" trolls. :)

      2. By Henning () henning@ on mailto:henning@

        3.3 has ProPolice on all platforms except hppa - but not for the Kernel.
        3.4 has ProPolice porrotected kernels as well (except for the install media)

  5. By Chris Humphries () chris@unixfu.net on http://unixfu.net/

    even though this hole/bug/whatever you want to call it is pretty lame, it still goes to show that to those that think openbsd is a brick house, change your way of thinking. imagine it is not a brick house and has holes waiting to be discovered.

    to halfass quote a line from swingers, "it is a bunny, a little cute bunny, and you are this bear, this bear with huge craws!".

    alot of the propaganda seems to inhibit people's mindset in thinking that it is secure and there is no way, they are little ol' programmer can break into it and find holes that other obviously more competent and skilled programmers would have missed or not looked for.

    at least it is a first step. dont let the propaganda ruin your mind. there are plenty of holes in everything, just gotta find them, and openbsd is no exception :D

    Comments

    1. By tony () tony@libpcap.net on mailto:tony@libpcap.net

      is this exploitable in 3.4? I would imagine one of the new technologies implemented (ProPolice, W^X, etc) would catch and stop this, no?

    2. By Anonymous Coward () on

      Yeah, a 'local' exploit that's not vulnerable remotely... How scary! Now let's all forget OpenBSD all together because of this and go with something that's made insecure by default with new, daily insecurities...

      http://www.microsoft|redhat.com.

      Comments

      1. By Anonymous Coward () on

        or let's repeat your comment for the 20th time this has happened, yea, you sound much more intelligent.

        Comments

        1. By Anonymous Coward () on

          20th time? 1+0=20?

          Comments

          1. By Anonymous Coward () on

            wow, I'm really glad you use OpenBSD. I'm glad it keeps all the idiots in one place, far away from worthwhile projects instead of marketed crap.

            Comments

            1. By Anonymous Coward () on

              and who EXACTLY is keeping you here?

              why don't you just like, hmm, go away ?



    3. By djm () on

      I don't think that you will find any OpenBSD developer being complacent about security - that is why new stuff is constantly being done. Note that, on 3.4, this bug is a DoS and not a local root because of the proactive measures that were put in place during the 3.3-3.4 release cycle. I'm sure that 3.5 will make it even more difficult to exploit such bugs when they arise.

      Anyway, thanks Noir for auditing our kernel for us. Please keep sending your bug reports :)

      Comments

      1. By Anonymous Coward () on

        Note that, on 3.4 the other bug you labelled as a "reliability" issue IS EXPLOITABLE. And this is despite all of your pathetic efforts. You act like this is the first time this has happened. Generate a list of locally exploitable privilege escalation bugs in OpenBSD over its lifetime and compare this to Linux. I assure you the OpenBSD list is at least 3x as large. So much for your auditing and secure designs!

        Comments

        1. By gwyllion () on

          Sorry, but I think you should blame Georgi Guninski, because in his advisory he calls this bug an OpenBSD kernel panic and states that >

          In a later message to full-disclosure he thinks it might be exploitable: >

          Only yesterday it was announced by noir that this bug is exploitable: "it is the second one he squashed in the last 2-3 weeks without even understanding that the first one is exploitable doh! ..." The exploitation technique is new and noir will release a paper on kmem allocator (kernel heap) overflows: "i will be releasing a paper regarding kmem allocator (heap) overflows in kernel space and exploit for patch 005 will be in its content." and "i have only release the stack based exploit since there is nothing new in the technique but the heap technique deserves more explanation and attention than an exploit post ..."

          I'm sure that patch 005 will be labeled as a security fix instead of a reliability issue very soon (e.g. when noir releases more details).

        2. By gwyllion () on

          Retry (sorry for bad html)

          Sorry, but I think you should blame Georgi Guninski, because in his advisory he calls this bug an OpenBSD kernel panic and states that >

          In a later message to full-disclosure he thinks it might be exploitable: >

          Only yesterday it was announced by noir that this bug is exploitable: "it is the second one he squashed in the last 2-3 weeks without even understanding that the first one is exploitable doh! ..." The exploitation technique is new and noir will release a paper on kmem allocator (kernel heap) overflows: "i will be releasing a paper regarding kmem allocator (heap) overflows in kernel space and exploit for patch 005 will be in its content." and "i have only release the stack based exploit since there is nothing new in the technique but the heap technique deserves more explanation and attention than an exploit post ..."

          I'm sure that patch 005 will be labeled as a security fix instead of a reliability issue very soon (e.g. when noir releases more details).

        3. By gwyllion () on

          Retry #2 (sorry for bad html)

          Sorry, but I think you should blame Georgi Guninski, because in his advisory he calls this bug an OpenBSD kernel panic and states that By executing a specially crafted binary it is possible to cause kernel panic on at least OpenBSD 3.3 and 2.8.

          In a later message to full-disclosure he thinks it might be exploitable: After playing with the obsd kernel debugger i am not sure this is not exploitable.

          Only yesterday it was announced by noir that this bug is exploitable: it is the second one he squashed in the last 2-3 weeks without even understanding that the first one is exploitable doh! ... The exploitation technique is new and noir will release a paper on kmem allocator (kernel heap) overflows: i will be releasing a paper regarding kmem allocator (heap) overflows in kernel space and exploit for patch 005 will be in its content. and i have only release the stack based exploit since there is nothing new in the technique but the heap technique deserves more explanation and attention than an exploit post ...

          I'm sure that patch 005 will be labeled as a security fix instead of a reliability issue very soon (e.g. when noir releases more details).

        4. By Anonymous Coward () on

          Generate a list of locally exploitable privilege escalation bugs in OpenBSD over its lifetime and compare this to Linux. I assure you the OpenBSD list is at least 3x as large. So much for your auditing and secure designs!

          OK. If you are so sure of what you are saying, why don't you just generate such a list and publish it? Until you do, everything you say has to be taken with a "grain of salt" ...

          At least the OpenBSD group is trying. They never promised a 100% secure operating system, just something they'll try to secure.

        5. By tony () tony@libpcap.net on mailto:tony@libpcap.net

          actually, YOUR the one acting like this has never happened before. Its happened, its fixed, who cares.

          do you really have this much free time?

          Comments

          1. By Anonymous Coward () on

            YOU'RE

      2. By Anonymous Coward () on

        So can you stop having double standards and move the "reliability" fix over to the security page? Unless you want to prove that it's not exploitable, that is. You're lying to your users by keeping it on the other page...anything to save face I guess.

        OpenBSD priorities:

        1) marketing
        2) preserving image through lies
        ...
        999) security

        Comments

        1. By Dunceor () on

          it's damn easy, if you don't like it, don't use it or make it better yourself...

        2. By Anonymous Coward () on

          You expect them to prove that a given piece of software is not exploitable? Thats one of the stupidest things i've ever heard.

          I've got one for you... there is an unpublished remote root exploit in linux. Now go prove it doesn't exist. (sounds stupid doesn't it, but thats just what your're asking us to do)

          Until the exploit is published or there is evidence of breakins, you're just talking about hearsay, which doesn't amount to crap.

          Comments

          1. By Anonymous Coward () on

            hearsay, you mean what you call OpenBSD's labelling of the bug as a "reliability" issue? By naming it such, they are essentially claiming it is unexploitable. If it were possibly exploitable, it should have been on the security page. No matter, the developers will have their collective asses handed to them soon enough, and maybe then they'll stop their habit of marking exploitable bugs non-exploitable as quickly as they can.

            Comments

            1. By Anonymous Coward () on

              No matter, the developers will have their collective asses handed to them soon enough

              This gets said all the time, and still no one has stood up with a hand big enough to hold all the developer's asses.

          2. By Anonymous Coward () on

            Also, I'm curious how many of you idiots would be willing to put your money where your mouth is. If you really believe in the security of OpenBSD, post your IP and a username/pass to the world and see that the box isn't owned within minutes. Seriously, OpenBSD users are the equivalent to stupid corporate CEOs, eager to accept any marketing tripe that claims will make them secure. I like how you think that until an exploit is published, it doesn't exist. Especially when the exploit recently published was developed in February of this year...I guess it didn't exist for those many months while it was being used to own OpenBSD machines. The fact that OpenBSD says your machines are secure makes you inheritly less secure than everyone else. Intelligent people realize that no system is secure, and take measures to add additional protection to their systems. You rely on the word of the OpenBSD developers, the same people that wrote these stupid bugs into your OS. Can someone explain why OpenBSD is the secure OS when NetBSD has not had half of the exploitable local root holes that OpenBSD has? You people have no facts, your entire set of beliefs regarding your OS are based on hearsay.

            Comments

            1. By Anonymous Coward () on

              You people have no facts, your entire set of beliefs regarding your OS are based on hearsay.

              Just like your various rants throughout this story!

              We have so much in common, let's make out.

            2. By tedu () on

              err, you mean how netbsd just fixed a bunch of the same issues in ibcs2 but hasn't sent out any patches or advisories? is that what makes them twice as secure?

              Comments

              1. By Anonymous Coward () on

                Just like openbsd sometimes "forget" to send out an advisory and silently patches some holes???

                Comments

                1. By Dunceor () on

                  you talk alot and show little..
                  Give us evidence of patches that hasn't been followed by an advisory?

                  Comments

                  1. By Anonymous Coward () on

                    http://www.openbsd.org/cgi-bin/cvsweb/src/sys/kern/sysv_sem.c

                    backported to 3.3 and no announcement?

    4. By Anonymous Coward () on

      Thanks for saying something so obvious. Let's hope people dont pretend you are smart...

      I dont get from where you took these ``propagand'' crap, since I cant find it under openbsd.org. Perhaps you are talking about some openbsd users, but mind you it happens everywhere.

      Now we can back to our know agenda, since no one stated the war was over.

  6. By Anonymous Coward () on

    what ever happend to that isakmpd bug?
    wasent it serious enough to get a fix or is it still beeing worked on?

    Comments

    1. By gwyllion () on

      I think it IS fixed in -current: http://marc.theaimsgroup.com/?l=openbsd-cvs&m=106813433329523&w=2
      Ask ho@ if this will be included in 3.4-stable.

      Comments

      1. By gwyllion () on

        Sorry, this doesn't fix all the payload handling flaws according to http://marc.theaimsgroup.com/?l=bugtraq&m=106822922900507&w=2

  7. By Anonymous Coward () on

    ... that the likes of noir are out there trying to find holes and flaws in the design of the OpenBSD kernel.

    The reason I say this is because otherwise these things might go unnoticed. We still need the black hats.

    OpenBSD courts this sort of problem by claiming to be the most `proactivly` secure OS. THAT is a red flag to a bull .. er.. cracker.

    That chip-on-their-shoulder might make them offensive but if you want improved security you have to take the rough with the smooth.

    Opponants of OpenBSD take great delight in any minor damage they can inflict, because it is OpenBSD, they will not disclose these problems publicly.

    Hell, if so many peoples OpenBSD boxes were being 0wn3d then more sys-admins would be kicking off about it publicly and not doing a quiet switch.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]