Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

[ Create a new account ]

Remote Exploit Discovered for OpenBSD

Posted by samzenpus on Thu Mar 15, 2007 12:13 AM
from the patch-it-up dept.
An anonymous reader writes "OpenBSD is known for its security policies, and for its boast of "only one remote exploit in over 10 years". Well, make that two, because Core Security has found a remotely exploitable buffer overflow in the OpenBSD kernel. Upgrade your firewalls as soon as possible."
This discussion has been archived. No new comments can be posted.
Display Options Threshold:
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • WHOA WTF (Score:2, Funny)

    by inode_buddha (576844) on Thursday March 15 2007, @12:19AM (#18358465)
    (Last Journal: Thursday October 02 2003, @03:46PM)
    freakin rare event, hell must have frozen over! /me takes a snapshot of the moment and feels badly for all the BSD-folk
    • Re:WHOA WTF by Anonymous Coward (Score:1) Thursday March 15 2007, @12:24AM
    • Re:WHOA WTF by The Mad Debugger (Score:1) Thursday March 15 2007, @01:00AM
    • Re:WHOA WTF by packeteer (Score:2) Thursday March 15 2007, @07:05AM
      • Re:WHOA WTF by br0k_sams0n (Score:1) Thursday March 15 2007, @09:52AM
        • Re:WHOA WTF (Score:4, Informative)

          by Chris Burke (6130) on Thursday March 15 2007, @02:07PM (#18366083)
          (http://slashdot.org/)
          If the team were as security conscious as you claim, they wouldn't have simply dismissed it and would have given the issue more serious consideration.

          They didn't simply dismiss it. They fixed the bug. At that point the question of how severe the vulnerability is only affects how critical getting the patch for the bug is. Being security conscious, they don't want to push out a patch without sufficient testing -- possibly causing new vulnerabilities -- unless they have to. When shown that the issue was in fact a remote exploit, they did not dismiss the issue then either, they upgraded the status of the issue and marked the patch as urgent.

          All of this is perfectly consistent with security consciousness.

          A team which does not take security seriously would have denied that there was a bug at all, would not have the fix, and would have found a way to claim that despite being shown exploit code for a remote vulnerability, it wasn't in fact a big deal. But that isn't what happened.

          I've always thought of the BSDs (Net and Open anyway) as a smaller attack vector, nothing inherently more secure. They don't have a monopoly on smart developers and all humans make mistakes.

          It is foolish to think that because all humans make mistakes, all humans make the same number and severity of mistakes, and have the same methods of identifying and correcting mistakes. For the same reason, it is foolish to think that because all software has bugs, that all software is equally buggy and the bugs are of equal severity. It is the attention payed to security, the methodologies of writing secure code, that help prevent bugs and make code that is truly inherently more secure.

          OpenBSD gets a lot of scrutiny in the security world exactly for the reason that people deploy it because of its security. It may be a smaller attack vector due to market share, and due to it being harder to crack than what your typical army of script kiddies can handle. This does not mean it is not thoroughly poked and prodded by experts, nor does it mean that inherently superior security is an illusion.
          [ Parent ]
    • Re:WHOA WTF (Score:4, Funny)

      by Misch (158807) on Thursday March 15 2007, @09:09AM (#18361359)
      (http://www.paulmischler.com/)
      It was 81 degrees F in New Jersey [wunderground.com] yesterday, so hell didn't freeze over.
      [ Parent ]
      • Re:WHOA WTF by HAKdragon (Score:2) Thursday March 15 2007, @04:00PM
    • 1 reply beneath your current threshold.
  • Heh (Score:5, Funny)

    by cyberbob2351 (1075435) on Thursday March 15 2007, @12:20AM (#18358467)
    (http://cosmicinteractive.com/)
    From TFA:

    Remotely Exploitable: Yes
    Locally Exploitable: No

    That right there is the biggest slap in the face! Everyone should have the freedom to fux0r their own machine!

    Opensource my ass...
    • Re:Heh by bean123456789 (Score:2) Thursday March 15 2007, @11:27AM
    • Re:Heh by Craig Davison (Score:2) Thursday March 15 2007, @03:48PM
    • Re:Heh by ArsenneLupin (Score:2) Thursday March 15 2007, @04:31AM
    • 1 reply beneath your current threshold.
  • Well done, the OpenBSD team. (Score:5, Insightful)

    by Anonymous Coward on Thursday March 15 2007, @12:21AM (#18358475)
    Well done. It's not an easy feat to create an OS with so little exploits. The team and Microsoft should take a leaf out of your book.
  • It's a feature (Score:4, Funny)

    by andy314159pi (787550) on Thursday March 15 2007, @12:21AM (#18358479)
    (Last Journal: Thursday June 07, @02:55PM)

    Vulnerability Description
    The OpenBSD kernel contains a memory corruption vulnerability in the code that handles IPv6 packets. Exploitation of this vulnerability can result in:
    1) Remote execution of arbitrary code at the kernel level on the vulnerable systems (complete system compromise), or;
    2) Remote denial of service attacks against vulnerable systems (system crash due to a kernel panic)

    I think they just found the Windows2003 Server Emulator.
    • Re:It's a feature (Score:5, Informative)

      by ArsenneLupin (766289) on Thursday March 15 2007, @01:43AM (#18358861)

      I think they just found the Windows2003 Server Emulator.
      Joking aside, finding a bug in BSD networking code could indeed mean that various Windows versions have that very same bug. Hats, to your keyboards!
      [ Parent ]
  • by Anonymous Coward on Thursday March 15 2007, @12:21AM (#18358483)
    * 2007-02-20: First notification sent by Core.
    * 2007-02-20: Acknowledgement of first notification received from the OpenBSD team.
    * 2007-02-21: Core sends draft advisory and proof of concept code that demonstrates remote kernel panic.
    * 2007-02-26: OpenBSD team develops a fix and commits it to the HEAD branch of source tree.
    * 2007-02-26: OpenBSD team communicates that the issue is specific to OpenBSD. OpenBSD no longer uses the term "vulnerability" when referring to bugs that lead to a remote denial of service attack, as opposed to bugs that lead to remote control of vulnerable systems to avoid oversimplifying ("pablumfication") the use of the term.
    * 2007-02-26: Core email sent to OpenBSD team explaining that Core considers a remote denial of service a security issue and therefore does use the term "vulnerability" to refer to it and that although remote code execution could not be proved in this specific case, the possibility should not be discarded. Core requests details about the bug and if possible an analysis of why the OpenBSD team may or may not consider the bug exploitable for remote code execution.
    * 2007-02-28: OpenBSD team indicates that the bug results in corruption of mbuf chains and that only IPv6 code uses that mbuf code, there is no user data in the mbuf header fields that become corrupted and it would be surprising to be able to run arbitrary code using a bug so deep in the mbuf code. The bug simply leads to corruption of the mbuf chain.
    * 2007-03-05: Core develops proof of concept code that demonstrates remote code execution in the kernel context by exploiting the mbuf overflow.
    * 2007-03-05: OpenBSD team notified of PoC availability.
    * 2007-03-07: OpenBSD team commits fix to OpenBSD 4.0 and 3.9 source tree branches and releases a "reliability fix" notice on the project's website.
    * 2007-03-08: Core sends final draft advisory to OpenBSD requesting comments and official vendor fix/patch information.
    * * 2007-03-09: OpenBSD team changes notice on the project's website to "security fix" and indicates that Core's advisory should reflect the requirement of IPv6 connectivity for a successful attack from outside of the local network.
    * 2007-03-12: Advisory updates with fix and workaround information and with IPv6 connectivity comments from OpenBSD team. The "vendors contacted" section of the advisory is adjusted to reflect more accurately the nature of the communications with the OpenBSD team regarding this issue.
    * 2007-03-12: Workaround recommendations revisited. It is not yet conclusive that the "scrub in inet6" directive will prevent exploitation. It effectively stops the bug from triggering according to Core's tests but OpenBSD's source code inspection does not provide a clear understanding of why that happens. It could just be that the attack traffic is malformed in some other way that is not meaningful for exploiting the vulnerability (an error in the exploit code rather than an effective workaround?). The "scrub" workaround recommendation is removed from the advisory as precaution.
    * 2007-03-13: Core releases this advisory.



    Got owned, OpenBSD? /I kid I kid
  • Advisory Timeline (Score:4, Interesting)

    by fv (95460) * <fyodor@insecure.org> on Thursday March 15 2007, @12:26AM (#18358499)
    (http://insecure.org/)

    I'm a bit surprised that the summary didn't mention the rather interesting timeline in the Core advisory [seclists.org], which implies an attempted cover up. I don't know all the facts, so I'll let the document speak for itself:

    • 2007-02-20: First notification sent by Core.
    • 2007-02-20: Acknowledgement of first notification received from the OpenBSD team.
    • 2007-02-21: Core sends draft advisory and proof of concept code that demonstrates remote kernel panic.
    • 2007-02-26: OpenBSD team develops a fix and commits it to the HEAD branch of source tree.
    • 2007-02-26: OpenBSD team communicates that the issue is specific to OpenBSD. OpenBSD no longer uses the term "vulnerability" when referring to bugs that lead to a remote denial of service attack, as opposed to bugs that lead to remote control of vulnerable systems to avoid oversimplifying ("pablumfication") the use of the term.
    • 2007-02-26: Core email sent to OpenBSD team explaining that Core considers a remote denial of service a security issue and therefore does use the term "vulnerability" to refer to it and that although remote code execution could not be proved in this specific case, the possibility should not be discarded. Core requests details about the bug and if possible an analysis of why the OpenBSD team may or may not consider the bug exploitable for remote code execution.
    • 2007-02-28: OpenBSD team indicates that the bug results in corruption of mbuf chains and that only IPv6 code uses that mbuf code, there is no user data in the mbuf header fields that become corrupted and it would be surprising to be able to run arbitrary code using a bug so deep in the mbuf code. The bug simply leads to corruption of the mbuf chain.
    • 2007-03-05: Core develops proof of concept code that demonstrates remote code execution in the kernel context by exploiting the mbuf overflow.
    • 2007-03-05: OpenBSD team notified of PoC availability.
    • 2007-03-07: OpenBSD team commits fix to OpenBSD 4.0 and 3.9 source tree branches and releases a "reliability fix" notice on the project's website.
    • 2007-03-08: Core sends final draft advisory to OpenBSD requesting comments and official vendor fix/patch information.
    • 2007-03-09: OpenBSD team changes notice on the project's website to "security fix" and indicates that Core's advisory should reflect the requirement of IPv6 connectivity for a successful attack from outside of the local network. 2007-03-12: Advisory updates with fix and workaround information and with IPv6 connectivity comments from OpenBSD team. The "vendors contacted" section of the advisory is adjusted to reflect more accurately the nature of the communications with the OpenBSD team regarding this issue.
    • 2007-03-12: Workaround recommendations revisited. It is not yet conclusive that the "scrub in inet6" directive will prevent exploitation. It effectively stops the bug from triggering according to Core's tests but OpenBSD's source code inspection does not provide a clear understanding of why that happens. It could just be that the attack traffic is malformed in some other way that is not meaningful for exploiting the vulnerability (an error in the exploit code rather than an effective workaround?). The "scrub" workaround recommendation is removed from the advisory as precaution.
    • 2007-03-13: Core releases this advisory.

    -Fyodor
    Insecure.Org [insecure.org]

    • Re:Advisory Timeline (Score:5, Interesting)

      by evilviper (135110) on Thursday March 15 2007, @12:38AM (#18358585)
      (Last Journal: Monday October 15, @11:53PM)

      which implies an attempted cover up.

      Cover up? The OpenBSD team believed it was only a remote DoS vulnerability until proof of concept code was provided, and re-labeled it as such immediately.

      What part seems suspicious to you?
      [ Parent ]
    • Re:Advisory Timeline by LordEd (Score:2) Thursday March 15 2007, @12:40AM
      • They've earned a mulligan, I think (Score:4, Insightful)

        by peacefinder (469349) <aland&hevanet,com> on Thursday March 15 2007, @01:13AM (#18358763)
        (http://peacefinder.net/ | Last Journal: Wednesday October 24, @04:06PM)
        I'll spot them some skepticism or overconfidence. It's been proven again and again that they're right to think OpenBSD is a hard target, so it's understandable that they wanted to see proof before bumping their counter up.

        As for a "cover up"... well, if such a thing happend I'd say they must really suck at coverups, since we all know about it. :-)
        [ Parent ]
      • Re:Advisory Timeline (Score:5, Informative)

        by fv (95460) * <fyodor@insecure.org> on Thursday March 15 2007, @01:45AM (#18358873)
        (http://insecure.org/)

        I wouldn't call it a cover up. I would say its a case of overconfidence.

        That could be. And don't get me wrong -- I'm a big OpenBSD fan and even have one of their posters framed and hanging in my home. But I think they could have handled this better. Given that security is their main selling point, I'd like to see the OpenBSD guys treat all buffer overflows as potentially exploitable. In this case, it appears that the fix to 3.9 and 4.0 branches was delayed for an extra week until Core produced a working remote root exploit. The problem with requiring a working exploit from bug reporters is that most of them lack the ability or inclination (or both) to produce one. This bug just happened to be reported by some of the best exploit writers in the world.

        Also, even if the bug did only allow anyone to cause remote kernel panic on your OpenBSD firewall or server with a single packet, that is still a security vulnerability. They can call it a DoS vulnerability if they are sure one cannot lead to code execution.

        -Fyodor [insecure.org]

        [ Parent ]
        • Re:Advisory Timeline (Score:4, Insightful)

          by TheRaven64 (641858) on Thursday March 15 2007, @04:59AM (#18359675)
          (http://theravensnest.org/ | Last Journal: Sunday October 07, @07:05AM)

          it appears that the fix to 3.9 and 4.0 branches was delayed for an extra week until Core produced a working remote root exploit
          I think this makes sense, to be honest. If it's just a DoS, then I'd rather not put the code in my kernel until it's been well tested (I can remote-reboot my machine, if all else fails, and then apply the patch). If it's a remote code execution then it's pretty hard for any change to make it worse.

          I really like OpenBSD, but I really miss having an analogue of FreeBSD's portaudit utility. Since the source data used by portaudit provides OpenBSD and FreeBSD vulnerability info, I wonder if anyone has tried porting it...

          [ Parent ]
        • Re:Advisory Timeline by evilviper (Score:2) Thursday March 15 2007, @06:10AM
        • Re:Advisory Timeline by BlairQ (Score:1) Thursday March 15 2007, @08:19PM
    • Not really a coverup... by Grendel Drago (Score:2) Thursday March 15 2007, @12:41AM
    • Re:Advisory Timeline by Secret Rabbit (Score:3) Thursday March 15 2007, @12:52AM
    • Re:Advisory Timeline by ctzan (Score:3) Thursday March 15 2007, @04:06AM
    • Re:Advisory Timeline by ctzan (Score:1) Thursday March 15 2007, @12:55PM
    • 4 replies beneath your current threshold.
  • Obligatory (Score:1, Funny)

    by Anonymous Coward on Thursday March 15 2007, @12:26AM (#18358507)
    It was as if several dozen antiquated nameservers suddenly cried out in pain"
  • by Psychotria (953670) on Thursday March 15 2007, @12:27AM (#18358511)
    Perhaps it would be better to update the kernel
  • by Anonymous Coward on Thursday March 15 2007, @12:31AM (#18358529)
    There will be buffer overflows. The solution is to not use C for handling data from over the network. Use a language that has memory safety. I think JNode [jnode.org] is on the right track. They have a small amount of code (assembly in this case) for running the virtual machine, and everything else is done in Java. Java has no memory access. Buffer overflows of a certain kind can exist but the standard buffer overflow exploit is nearly impossible.

    I know, those who don't understand what I'm talking about will leap in and say, "Java has to run in a JVM and what language is the JVM written in? Ha! It's in C (or assembler) so it can still have buffer overflows!" This is so naive. First, the JVM runs Java code, which has no memory access. It does not run untrusted code handed to it over the net. Second, and most important, it is a very small piece of code with a rigorous definition of what it should do. It's possible to verify a small, rarely-changing bit of C code with a rigorous specification. It's not really possible to verify correctness of a huge constantly-changing C codebase, like the OpenBSD kernel and system utilities.

    Anyway, trying to have a huge secure codebase in C is an exercise in futility, as OpenBSD has shown. Relative to other operating systems, OpenBSD is small and feature-poor. And their dev team must be among the best in the world for eliminating these types of bugs. And yet they still get bitten by them.
  • Barely "remote" (Score:5, Informative)

    by _iris (92554) on Thursday March 15 2007, @12:36AM (#18358559)
    (http://drew.intercarve.net/)
    "remote" in this case only means "not local." It does not, in any way, mean "far away," as the attacker has to be able to inject fragmented IPv6 packets, which is extremely hard to control (impossible?) from the other side of a layer 3 device.
  • by Anonymous Coward on Thursday March 15 2007, @12:36AM (#18358567)
    Wow, OpenBSD's security rating just went from "999,999" on a scale of 1 to a million to "999,998" on a scale of 1 to a million.

  • Holy Cow, an OpenBSD Vuln? (Score:5, Funny)

    by Anonymous Coward on Thursday March 15 2007, @12:49AM (#18358651)
    Thank GOD I run the company webserver on NT!
  • who the hell.. (Score:1, Insightful)

    by Anonymous Coward on Thursday March 15 2007, @01:33AM (#18358829)
    ..uses IPv6? That's the first thing I turn off on every OS I've ever set up for a client (at least, ones where I can recompile the kernel).

    This is about as interesting as finding a hole in Gopher. (Except, well, Gopher is something from the past, and IPv6 is perpetually in the future [any day now, we'll all switch!]).
  • by rivaldufus (634820) on Thursday March 15 2007, @01:51AM (#18358899)
    gloating. Perhaps they know of an OS with a better record?

  • pablumfication (Score:3, Interesting)

    by vocaro (569257) * <trevor@vocaro.com> on Thursday March 15 2007, @01:55AM (#18358915)
    Can anyone explain what pablumfication means? The only hit [google.com] is the very same report. I thought maybe it was pablumification [google.com], but that only gets two more hits.
  • OpenBSD Website (Score:5, Informative)

    by Anonymous Coward on Thursday March 15 2007, @02:45AM (#18359123)
    From the OPENBSD Website:
    Only two remote holes in the default install, in more than 10 years!

    At least they don't hide it.
  • by iamacat (583406) on Thursday March 15 2007, @03:18AM (#18359227)
    This bug just crashes the machine. Anyone who uses a desktop or notebook knows that crashes happen from time to time, regardless of the OS. There is no known way to run attacker's code, and TFA suggests that there is unlikely to be one.
  • by minus9 (106327) on Thursday March 15 2007, @03:20AM (#18359235)
    (http://slashdot.org/)
    OpenBSD is only a target because it is so ubiquitous. If Microsoft windows ever becomes as popular, it too will become the target of such attacks. ;)
  • If only.... (Score:1, Troll)

    by leereyno (32197) on Thursday March 15 2007, @03:36AM (#18359317)
    (http://what-was-lost.blogspot.com/ | Last Journal: Tuesday May 04 2004, @09:56PM)
    If only OpenBSD were suitable for anything beyond a firewall.

    • Re:If only.... by Noryungi (Score:2) Thursday March 15 2007, @04:18AM
      • Re:If only.... by TheRaven64 (Score:2) Thursday March 15 2007, @05:40AM
  • Fixed in OpenBSD 4.1 (Score:3, Interesting)

    by chrysalis (50680) on Thursday March 15 2007, @04:03AM (#18359427)
    (http://00f.net/)
    Fortunately, that bug has been fixed before the OpenBSD 4.1 CDs were sent to the press.

  • by master_p (608214) on Thursday March 15 2007, @05:26AM (#18359781)
    Isn't it enough? even the best programmers can make a mistake with C (and no, it may be programmers that make the mistakes, but you have to be at least a Q in order to make an 100% correct C program).

    Can we please stop using C?

    http://it.slashdot.org/comments.pl?sid=224594&cid= 18191856 [slashdot.org]
  • by badger.foo (447981) on Thursday March 15 2007, @05:53AM (#18359883)
    (http://bsdly.blogspot.com/)
    "OpenBSD systems using default installations are vulnerable because the default pre-compiled kernel binary (GENERIC) has IPv6 enabled and OpenBSD's firewall does not filter inbound IPv6 packets in its default configuration."

    - the default configuration on a fresh install actually has pf disabled (no two networks are exactly alike, and if you enable pf but do not supply your own rule set, a default rule set which passes dns, ssh and some icmp is enabled). Then again, any sane config with pf enabled will have "block all" as the default action and only pass inet6 if you are actually using inet6. This means that the vast majority of OpenBSD machines out there will have the equivalent of the advisory's block rule in their rule sets already.

    "However, in order to exploit a vulnerable system an attacker needs to be able to inject fragmented IPv6 packets on the target system's local network. This requires direct physical/logical access to the target's local network -in which case the attacking system does not need to have a working IPv6 stack- or the ability to route or tunnel IPv6 packets to the target from a remote network."

    This narrows the scope quite a bit.

    Essentially the sky did not fall this time either, but I can see the OpenBSD developers taking another pass of "reading the code much like the devil reads the bible" over the ipv6 stack and the general neighborhood once again.

    However, OpenBSD users have been instructed to update their systems already.
  • where's puffy? (Score:2)

    by noldrin (635339) on Thursday March 15 2007, @08:35AM (#18360991)
    what, do they change their logo each time an exploit is found
    • 1 reply beneath your current threshold.
  • Forced release? (Score:5, Insightful)

    FTFA:

    2007-02-21: Core sends draft advisory and proof of concept code that demonstrates remote kernel panic.
    2007-02-26: OpenBSD team develops a fix and commits it to the HEAD branch of source tree.
    [...]
    2007-03-05: OpenBSD team notified of PoC availability.
    2007-03-07: OpenBSD team commits fix to OpenBSD 4.0 and 3.9 source tree branches and releases a "reliability fix" notice on the project's website.
    [...]
    2007-03-13: Core releases this advisory.
    Release Mode: FORCED RELEASE

    Kudos to Core Security for finding an exploit in OpenBSD code. Seriously, that's impressive. However, it sounds like they're a little too pleased with themselves. "Forced release"? I guess that's technically true, in the sense that a feather exerts a gravitational force on the Earth.

    In a nutshell, they reported a problem and OpenBSD fixed it. Then they demonstrated that it was a more serious problem, and OpenBSD backported the fix to the current releases and announced it on their website. After reading the whole timeline, I'm not sure what else they were supposed to have done so that Core wouldn't be "forced" to announce the vulnerability that OpenBSD publicized on their own site as a "security fix" three days earlier.

  • Better Languages (Score:2)

    by RAMMS+EIN (578166) on Thursday March 15 2007, @08:59AM (#18361243)
    (http://inglorion.net/ | Last Journal: Thursday October 06 2005, @07:17AM)
    I'm not pretending I'm more knowledgeable about security than the OpenBSD devs, but I have to say this: if they had programmed the thing in a safe language (specifically, one which does not allow buffer overflows to be coded), this vulnerability would not have occurred.

    The fact that the OpenBSD team didn't catch this vulnerability, despite their expertise and effort, means it could happen to anyone. It would be well to remember this next time someone says "yeah, C is an unsafe language, but you just have to be careful to check your bounds and use fgets instead of gets". Sure, no useful language can completely prevent one from writing insecure code (so there is always responsibility on the part of the programmer), but every vulnerability that the language rules out is a win.

    C is one of the worst languages security-wise (and, arguably, productivity-wise). I would hesitate to call anything written in C "secure".
  • function pointers (Score:2)

    by Sloppy (14984) on Thursday March 15 2007, @09:45AM (#18361829)
    (http://www.biglumber.com/ | Last Journal: Tuesday September 18, @12:25PM)
    In the meat of the article, it talks about a structure called m_ext which is inside of mbuf, and..

    This second structure contains the variable ext_free, a pointer to a function called when the mbuf is freed. Overwriting a mbuf with a crafted ICMP v6 packet (or any type of IPv6 packet), an attacker can control the flow of execution of the OpenBSD Kernel when the m_freem() function is called on the overflowed packet from any place on the network stack.

    I never really looked at OpenBSD under the hood, so I'm kind of surprised that there are function pointers being stored inside of complex dynamic structures like that. If I were on the team, I'd be taking a long hard look at every damn function pointer that gets stored anywhere, to make sure none of those can get overwritten either. Sheesh, I normally think of the code segment and the stack as the only places where this kind of crap can happen, but obviously that's just not the case. Yeah, in hindsight, I'm a moron.

    Another thing that springs to mind here, is that I wonder if the basic idea behind this attack could be applied even to "safe" languages; anywhere where there's some sort of callback that gets stored with data. Even in a Python program, if you store a callback of some kind inside of some data, and someone figures out how to corrupt that data, the callback could end up not going where the programmer expected it to. Hm. Of course, the trick is: how would an attacker corrupt the data? That's where "safe" languages still do feel safer.

    Anyway, all that aside, this story doesn't really change my overall admiration for the OpenBSD team. It's a shame to see them not be able to keep their undefeated bragging rights, though.

  • OpenBSD and the security myth (Score:3, Interesting)

    by jnf (846084) on Thursday March 15 2007, @11:44AM (#18363983)
    I think its interesting that BSD doesn't consider DoS attacks as being a vulnerability anymore, this is especially interesting when you consider that many DoS attacks that are reported end up being remote code execution vulnerabilities that the given researcher couldn't figure out, or the vendor didn't take the time to figure out. This is especially the case with OpenBSD if you look at the CORE timeline, the OpenBSD team attempted to say remote code execution was impossible, as they did when Dowd found the OpenSSH bug, and it took a proof of concept to make them accept they had another bug.

    If you cross reference DoS attacks against OpenBSDs changelog and figure that even a small amount (say 10%) of them were remotely exploitable (which is being kind), then you have a lot of remote bugs in OpenBSD and even more in FreeBSD. The fact that the vendor doesn't call them bugs just brings images of DJB to mind, but it doesn't impact the fact that your box could get owned.

    What this ultimately means is that, OpenBSD is pretty good when it comes to security, but that their party line is mostly marketing hype. I just submitted a paper to a few conferences dealing with a given bug I've found, it also affects OpenBSD (but it's not a default remote root bug for them), but what it does show is how proactively secure they are, because they copy/pasted the same section of code as everyone else and missed a very obvious bug.

  • by Myria (562655) on Thursday March 15 2007, @12:21PM (#18364647)
    The Firefox team somehow has a better policy about this type of bug than the OpenBSD team. Denial-of-service bugs that show signs of memory corruption are considered the same as actual remote code execution exploits, even if no method of executing code is known. (Of course, "remote code execution" in Firefox means visiting a malicious website.) Such exploits appear in red on this page along with the direct exploits: http://www.mozilla.org/projects/security/known-vul nerabilities.html [mozilla.org]
  • by CoolCat23 (923066) on Thursday March 15 2007, @01:46PM (#18365799)
    Can't understand why you here at /. spit at Windows everytime a mere new bug is found in it, when OpenBSD just doubled its known bugs list !
  • by jbburks (853501) on Thursday March 15 2007, @02:17PM (#18366249)
    Press release from the borg marketing machine: The number of bugs in the OpenBSD system is doubling every year!
  • For the conspiracy nutters... (Score:1, Informative)

    by Anonymous Coward on Friday March 16 2007, @09:17AM (#18374457)
    From:

    http://marc.info/?l=openbsd-misc&m=117404837006368 &w=2 [marc.info]

    List: openbsd-misc
    Subject: Re: Important OpenBSD errata
    From: Theo de Raadt
    Date: 2007-03-16 11:40:54
    Message-ID: 200703161140.l2GBesJD020460 () cvs ! openbsd ! org

    > This is idiotic, a big hole was found and the devs pissed about
    > because they didn't want to admit it.

    Noone in OpenBSD is pissed off about this. We posted the bug fix as
    soon as we became aware of the problem. The timeline goes like this:

    1) We were told there was a mbuf crash, which could remotely CRASH
    the machine. There was no proof that more could be done, not even
    a whiff.

    2) We commited the fix, about 24 hours later. It took a few days to
    get the errata up because the people who do that were at a conference.
    It was labelled as a RELIABILITY FIX because everyone felt it was just
    a CRASH. I then entered into a long conversation with Core explaining
    why we label crash fixes (even remote) as RELIABILITY FIXES.

    3) Core felt maybe something more could be done and continued working,
    and ONE WEEK LATER later, finally managed to show us brand new code
    which showed that intrusion was possible. Before that moment, it
    was still just confirmed to be a CRASH.

    4) A few hours after we become aware that it was more than a CRASH, we
    changed the advisory to say it was a real security risk. We first had
    to get the patch into -stable,

    I changed index.html to talk about there being TWO remote holes in
    more than 10 years, without even discussing this with any other
    developer, because I knew it was true. Other developers in the group
    were stunned to see me change it.

    5) Core decided that their advisory should include their interpretation
    of our discussion as to why OpenBSD labels crash fixes as RELIABILITY
    FIXES. Three times I told them that I thought that was a mistake,
    and that the public would not understand the reasoning as they wrote
    it.

    That is what happened. If you don't believe me, mail Ivan Arce at
    Core and ask him if any of the 5 points above are wrong. Come on, go
    ask him if I am a liar... go ahead.

    Yes, some of the press got it wrong too, and part of that I feel is
    Ivan Arce's fault. He should have been more cautious at explaining
    the complex discussion OpenBSD had with Core, where we explained why
    we label errata for remote crashes a Reliability Fix. Or he should
    have skipped it altogether.

    He even went around telling the press that this shows that IPV6 is a
    risky new technology, when the fact is that this was a mbuf corruption
    bug, in code that all parts of the network stack could potentially use
    in the same way. He's got his layers wrong. But finding bugs in
    other people's software lets companies like Core sell themselves as
    experts. They are experts, but the good press they get should not
    cost us in this way.

    Let's see... the fsck_ffs fix pedro commited a few hours ago. That
    fixes a serious problem where fsck fails to spot filesystem
    corruption. Should we spend time fully assessing how rare or common
    this situation is, and then errata it up the stream as fast as
    possible, maybe even consider if there are security risks from such
    filesystem corruption? Come on. Yet that is what some non-experts
    moan for. They want projects with only a few people (who are doing
    this for a hobby) to struggle down these well-defined p
  • Theo de Raadt's response (Score:2, Informative)

    by whamett (917546) on Saturday March 17 2007, @06:07AM (#18384555)

    There's an informative message [theaimsgroup.com] from OpenBSD project leader Theo de Raadt outlining the timeline. Excerpt:

    Noone in OpenBSD is pissed off about this. We posted the bug fix as soon as we became aware of the problem. The timeline goes like this:

    1) We were told there was a mbuf crash, which could remotely CRASH the machine. There was no proof that more could be done, not even a whiff.

    2) We commited the fix, about 24 hours later. It took a few days to get the errata up because the people who do that were at a conference. It was labelled as a RELIABILITY FIX because everyone felt it was just a CRASH. I then entered into a long conversation with Core explaining why we label crash fixes (even remote) as RELIABILITY FIXES.

    3) Core felt maybe something more could be done and continued working, and ONE WEEK LATER later, finally managed to show us brand new code which showed that intrusion was possible. Before that moment, it was still just confirmed to be a CRASH.

    4) A few hours after we become aware that it was more than a CRASH, we changed the advisory to say it was a real security risk. We first had to get the patch into -stable,

    I changed index.html to talk about there being TWO remote holes in more than 10 years, without even discussing this with any other developer, because I knew it was true. Other developers in the group were stunned to see me change it.

    5) Core decided that their advisory should include their interpretation of our discussion as to why OpenBSD labels crash fixes as RELIABILITY FIXES. Three times I told them that I thought that was a mistake, and that the public would not understand the reasoning as they wrote it.

    That is what happened. If you don't believe me, mail Ivan Arce at Core and ask him if any of the 5 points above are wrong. Come on, go ask him if I am a liar... go ahead.

    Yes, some of the press got it wrong too, and part of that I feel is Ivan Arce's fault. He should have been more cautious at explaining the complex discussion OpenBSD had with Core, where we explained why we label errata for remote crashes a Reliability Fix. Or he should have skipped it altogether.

    He even went around telling the press that this shows that IPV6 is a risky new technology, when the fact is that this was a mbuf corruption bug, in code that all parts of the network stack could potentially use in the same way. He's got his layers wrong. But finding bugs in other people's software lets companies like Core sell themselves as experts. They are experts, but the good press they get should not cost us in this way.

    Core Security certainly deserves credit for finding this. Their advisory and de Raadt's timeline, however, give rather different impressions. Perhaps reading both will give a more complete picture.

  • Amiga : ZERO exploits !! (Score:2, Funny)

    by Anonymous Coward on Thursday March 15 2007, @01:06AM (#18358729)
    Amiga : ZERO exploits !! About as many users !!
    [ Parent ]
  • Re:Moo (Score:5, Funny)

    by noz (253073) on Thursday March 15 2007, @01:09AM (#18358743)

    See! I told you ipv6 was evil!
    You mean ipv666 don't you?
    [ Parent ]
    • Re:Moo by Zonk (troll) (Score:2) Thursday March 15 2007, @10:52AM
  • Re:Not in the default install (Score:5, Informative)

    No, IPv6 is enabled in the default install, though it does use only link-local addresses by default. This means that the attacker has to be on the same layer-2 network as the victim, but this is still classified as a remote exploit. Theo agreed, and the homepage [openbsd.org] has already been updated.
    [ Parent ]
  • Re:Moo (Score:4, Funny)

    by BrainInAJar (584756) on Thursday March 15 2007, @01:15AM (#18358775)
    An IP for everyone. Bah!

    why, That's Communism!
    [ Parent ]
  • by tfeserver (1065880) on Thursday March 15 2007, @01:18AM (#18358785)
    (http://tfeserver.be/)
    Just OpenBSD. There are lot of other *bsd's.
    [ Parent ]
  • Re:Moo (Score:2)

    by HansF (700676) on Thursday March 15 2007, @03:26AM (#18359267)
    (Last Journal: Tuesday June 20 2006, @07:47AM)
    Ipv4 was about 0.71 address per person, ipv6 is more like 47000 ip's per person.
    [ Parent ]
    • Wrong... (Score:5, Interesting)

      by Phil John (576633) <phil@webstarsl t d .com> on Thursday March 15 2007, @04:05AM (#18359431)

      ...it's roughly 5.67137278 × 10^28 IP's per person

      Or, as a recent Ars article [arstechnica.com] put it (much better than I ever could):

      To put this into perspective: there are currently 130 million people born each year. If this number of births remains the same until the sun goes dark in 5 billion years, and all of these people live to be 72 years old, they can all have 53 times the address space of the IPv4 Internet for every second of their lives. Let nobody accuse the IETF of being frugal this time around.
      [ Parent ]
      • Re:Wrong... by obarthelemy (Score:1) Thursday March 15 2007, @05:25AM
        • Re:Wrong... by Phil John (Score:2) Thursday March 15 2007, @06:19AM
          • Re:Wrong... by Short Circuit (Score:1) Thursday March 15 2007, @07:19AM
            • Re:Wrong... by Samhain (Score:1) Thursday March 15 2007, @08:54AM
  • 16 replies beneath your current threshold.