Forgot your password?
typodupeerror
Security Operating Systems BSD

Remote Exploit Discovered for OpenBSD 338

Posted by samzenpus
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.

Remote Exploit Discovered for OpenBSD

Comments Filter:
  • WHOA WTF (Score:2, Funny)

    by inode_buddha (576844)
    freakin rare event, hell must have frozen over! /me takes a snapshot of the moment and feels badly for all the BSD-folk
    • by packeteer (566398)
      If there was never any exploits found THEN you should worry. If nobody is finding anything you can guess that nobody is looking hard. If you find them every now and then but rarely it says that as we have known for a long time, nothing is perfect, and yet this OS is almost perfect. One of the main reasons for things like BSD being so secure is the fact that people are checking for exploits even though people are quite confident there are none.
  • Heh (Score:5, Funny)

    by cyberbob2351 (1075435) on Thursday March 15, 2007 @01:20AM (#18358467) Homepage
    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...
  • by Anonymous Coward on Thursday March 15, 2007 @01: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.
    • by Anonymous Coward on Thursday March 15, 2007 @01:37AM (#18358575)
      You think the problem is that Microsoft can't create a secure OS? You don't think the problem is all the legacy crap, and the everything under the sun and everything to everyone demands placed upon it? Not that what OpenBSD has achieved as a track record isn't impressive. But serving one master (of one's own choosing) well, it not the same thing as being the most favored servent to the most masters.
      • Re: (Score:3, Interesting)

        by hattmoward (695554)
        Did you know that systems like POSIX ACLs and SELinux work while maintaining compatibility with software written before these systems were implemented? And that the basic Unix-like environment, although there have been quirks going from vendor to vendor, has remained basically the same for users and developers alike for years? Microsoft has had trouble locking down Windows not because of backward compatibility, but the users. Not only does OpenBSD choose, as you say, who their software targets, but they
    • by Kandenshi (832555) on Thursday March 15, 2007 @01:38AM (#18358579)
      I heard a rumour that Microsoft did indeed look to the idea of emulating OpenBSD's security practices as a company.

      Then someone pointed out the respective revenues of OpenBSD vs Microsoft, and the whole idea just seemed to evaporate.

      Someone decided that people don't care enough about the number of remote exploits found in a given OS. They were probably right.
      • by Just Some Guy (3352) <kirk+slashdot@strauser.com> on Thursday March 15, 2007 @09:52AM (#18361173) Homepage Journal

        I heard a rumour that Microsoft did indeed look to the idea of emulating OpenBSD's security practices as a company.

        Then someone pointed out the respective revenues of OpenBSD vs Microsoft, and the whole idea just seemed to evaporate.

        My company makes far more than the OpenBSD team brings in, and yet we still respect them and try to emulate their practices. I'm not sure what kind of hubris it takes to dismiss someone's ideas just because you have more money.

        • Re: (Score:3, Insightful)

          by Chris Burke (6130)
          I'm not sure what kind of hubris it takes to dismiss someone's ideas just because you have more money.

          It's not hubris, exactly. It's a matter of values. If what you value above all else is money, then the fact that they have less money -- compared to MS, they are effectively penniless -- means that their ideas are not important to you, even if technically good ideas. They won't help you get more money, ergo what you are doing is better than what they are doing.

          Your company values things other than money
          • Re: (Score:3, Insightful)

            by Just Some Guy (3352)

            Your company values things other than money, so you copy good practices even if they aren't going to earn you more money.

            My company values money an awful lot - it makes staying in business a bit easier. It's just that we take the long term view. Doing these things gives us a better reputation, which is critically important in our niche market. It also means fewer 2AM emergencies and easier maintenance. Basically, we've decided that OpenBSD's values are very profitable, even if they don't choose to dir

    • Re: (Score:3, Insightful)

      by drsmithy (35869)

      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 is when basically the only thing your OS does "in the default install" is allow SSH logins.

      (Which is not to attack the excellent work of the OpenBSD team, but comparing it to Windows is in this fashion is just asinine.)

      • by Tom (822) on Thursday March 15, 2007 @04:39AM (#18359333) Homepage Journal

        It is when basically the only thing your OS does "in the default install" is allow SSH logins.
        Which is more remote access than a default install of Windos contains. ;-)

        Ok, make that "more intentional remote access"...
      • by Richard_at_work (517087) <richardprice.gmail@com> on Thursday March 15, 2007 @05:20AM (#18359493)
        The default install of OpenBSD includes (from memory, so this is not exhaustive) SSHd, bind, apache and sendmail, all of which are included in the term 'Only two remote holes in the default install' - those codebases are as rigourously audited as anything else.
        • Re: (Score:3, Insightful)

          by drsmithy (35869)

          The default install of OpenBSD includes (from memory, so this is not exhaustive) SSHd, bind, apache and sendmail, all of which are included in the term 'Only two remote holes in the default install' [...]

          They're "included" in that the binaries are there, but they are not enabled (except SSH). Ie: they're not part of "the default install" as far as remote vulnerabilities goes.

          • They are actually deemed part of 'the default install' - otherwise the term would be 'the default configuration', which it isnt. Even SSH is not explicitly enabled on install, you have to answer a question during install to enable it.
    • Re: (Score:3, Funny)

      by VGPowerlord (621254)

      The team and Microsoft should take a leaf out of your book.

      What team, the A Team? Should take out Microsoft?

      I love it when a plan comes together.
    • Re: (Score:3, Funny)

      by TheDarkener (198348)
      ...Microsoft should take a leaf out of your book.
       
      Uhh, they did. TCP/IP stack.
       
      Of course, you can't ever say a leaf made the tree...
  • by andy314159pi (787550) on Thursday March 15, 2007 @01:21AM (#18358479) Journal

    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 @02: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!
      • Re: (Score:3, Insightful)

        by TheRaven64 (641858)
        Not in this case. This was a bug in the IPv6 code, which comes from the KAME project. The BSD TCP/IP stack used by some versions of Windows comes from the 4BSD series, pre-dating KAME (and IPv6 in general) by quite some years.
  • by Anonymous Coward
    * 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
  • Advisory Timeline (Score:4, Interesting)

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

    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 @01:38AM (#18358585) Journal

      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?
      • by jallen02 (124384)
        The whole remote kernel panics aren't "vulnerabilities" thing goes counter to how the entire software industry classifies security bugs.
        • Re: (Score:3, Informative)

          by Secret Rabbit (914973)
          LOL. So, then the OpenBSD team isn't part of the software industry?

          Because, they've never come up with anything security wise:

          http://en.wikipedia.org/wiki/OpenBSD_security_feat ures [wikipedia.org]

          Not at all.
        • Re:Advisory Timeline (Score:4, Informative)

          by LizardKing (5245) on Thursday March 15, 2007 @06:12AM (#18359719)

          A remote kernel panic is a reliability issue - you can't exploit a paniced system! The OpenBSD team couldn't see a way to exploit the issue, Core subsequently proved that a panic could be avoided and exploit code executed, at which time it was upgraded to a security issue by the OpenBSD team. No conspiracy necessary.

        • Re: (Score:3, Informative)

          by jdbo (35629)
          The term "cover-up" implies that they did something outside of their usual process of classifying bugs & the attendant patches.

          Except that they didn't; they classified it as a reliability issue (as they have done with many similar issues because they didn't see exploitability as of part of the problem ( Check out the history here: http://openbsd.org/errata40.html [openbsd.org] ; many kernel panic bugs going back several years are classified as "reliability" patches ). Once the proof-of-exploit was provided, they re-
    • by LordEd (840443)
      I wouldn't call it a cover up. I would say its a case of overconfidence. They didn't accept the fact that the buffer overflow was dangerous beyond a denial of service attack until it was proven to them. A denial of service attack in itself is more of a nuisance than a security risk.
      • by peacefinder (469349) <alan@dewitt.gmail@com> on Thursday March 15, 2007 @02:13AM (#18358763) Journal
        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. :-)
      • Re:Advisory Timeline (Score:5, Informative)

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

        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]

        • by TheRaven64 (641858) on Thursday March 15, 2007 @05:59AM (#18359675) Journal

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

        • by evilviper (135110)

          I'd like to see the OpenBSD guys treat all buffer overflows as potentially exploitable.

          They do. I have no doubt the change was made to the appropriate CVS branches (OPENBSD_3_9/OPENBSD_4_0), as hundreds of other improvements are, all the time (long after release). It would be vastly impractical for them to release a patch and errata for every such change made, on the off chance it might be exploitable.
    • They just asked for proof of concept code before they'd declare a remote control vulnerability. That's not really much of a coverup. If you were OpenBSD, wouldn't you want to be really, really sure you'd found a remote root vulnerability?

      Also, is IPv6 in the default install nowadays? If not, their slogan won't have to change.
      • Re: (Score:3, Informative)

        by evilviper (135110)

        Also, is IPv6 in the default install nowadays?

        "Nowadays?" How long has it been since you've tried OpenBSD?

        IPv6 has been enabled by default since v2.7 (June 2000), and fully supported by just about every included network program.
    • Re: (Score:3, Insightful)

      by Secret Rabbit (914973)
      I think you're reading too much into things. It's FAR more likely that the OBSD team has become somewhat overconfidenct in there code. As such, since remote exploit wasn't shown and was unlikely, they dismissed that.

      But, cover up? Yah right. Please, note that the OBSD team NEVER denied that a problem existed. They fixed it. It was only the wording that was in contest until remote execution was shown and they verified it.
    • Re: (Score:3, Informative)

      by ctzan (908029)

      From the bugtraq advisory:

      *Credits* This vulnerability was found and researched by Alfredo Ortega from Core Security Technologies. The proof-of-concept code included in the advisory was developed by Alfredo Ortega with assistance from Mario Vilas and Gerardo Richarte.

      From the OpenBSD CVS log:

      revision 1.27 date: 2007/02/26 20:15:33; author: claudio; state: Exp; lines: +2 -6 m_dup1() copies the packet header and allocates the mbuf cluster in the wrong order. M_DUP_PKTHDR needs to be called w

  • by Anonymous Coward
    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 lea
    • by Fnordulicious (85996) on Thursday March 15, 2007 @02:07AM (#18358733) Homepage
      Even the on the Lisp Machines the "kernel" code was implemented with manual memory management. There's a very simple reason for this. How do you implement the memory manager? It's a chicken and egg problem, so the lowest levels always have to do memory management by hand.

      Also, it's less efficient to simply use one heap for everything. Instead, an OS kernel written in a language with automatic memory management usually maintains large blocks of memory for the various tasks to work in, like an area for packet construction, an area for I/O buffers, etc. The automatic allocator and GC are told which area to work in, and then create or delete stuff in that area as needed.

      So no, it's not generally reasonable to implement the lower levels of any OS with automatic memory management. You're free to try, though.
      • "alloc final class PacketBuffer ..."

        Where that keyword tells the gc to use a separate allocation area for these objects. It's not hard to overcome the special challenges of kernel-level code in a safe language, it just takes a small amount of creativity. It's not like it hasn't been done before with Self, JavaOS, Singularity, etc.

        The actual reasons why operating system are not written in safe languages today is a little bit of stupidity and a lot that user apps are written in unsafe languages. Making som
    • by iamacat (583406)
      What advantage Java provides in memory safety and garbage collection is lost in the lack of local destructors. A method can put stuff in a temporary data structure or open a limited resource and then throw an exception without cleaning things up. finally blocks are not so hot when you have 20 things to cleanup in nested block structure. In fact, Java memory licks are quite common and tougher to debug than good C++ code. Someone should wake up and come up with a language that has memory safety AND support fo
  • Barely "remote" (Score:5, Informative)

    by _iris (92554) on Thursday March 15, 2007 @01:36AM (#18358559) Homepage
    "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 LordEd (840443)
      Most networks have multiple computers and devices. Odds are this system would hold more sensitive information and be used as a server. A successful attack vector would be to take over a less secure system to gain a foothold on the network, then use this attack to take over the main fortress.
    • Re:Barely "remote" (Score:5, Informative)

      by pchan- (118053) on Thursday March 15, 2007 @01:45AM (#18358617) Journal
      From the exploit text:

      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


      So nobody from the net can crack your machine, they must already me on your local net. This greatly reduces the scope of this attack.
  • by Anonymous Coward on Thursday March 15, 2007 @01: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.

  • by Anonymous Coward on Thursday March 15, 2007 @01:49AM (#18358651)
    Thank GOD I run the company webserver on NT!
  • pablumfication (Score:3, Interesting)

    by vocaro (569257) * <trevor@vocaro.com> on Thursday March 15, 2007 @02: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.
    • Re: (Score:3, Interesting)

      by chenjeru (916013)
      While 'pablumification' does seem to be a newly made word, the root 'pablum' is a bland children's porridge. The ever-handy Wikipedia has this to say:

      _In lower case, the word pablum is often used to describe anything bland, oversimplified and generally unsatisfying, especially a work of literature or speech. This usage is thought to derive from the cereal. Today, the word pablum and the original Latin word pabulum are often used interchangeably. In Canada, pablum remains as a generic reference to any instan
    • Re: (Score:3, Informative)

      by Cheapy (809643)
      Sure. Look at the given text for the first google hit. It says "disneyification." This lead me to believe this term was referring to "pablum". So I looked that up, and found out that "pablum" is used to describe oversimplification of something.

      Wikipedia has a good entry on Pablum.
  • OpenBSD Website (Score:5, Informative)

    by Anonymous Coward on Thursday March 15, 2007 @03: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.
  • 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. ;)
  • Fixed in OpenBSD 4.1 (Score:3, Interesting)

    by chrysalis (50680) on Thursday March 15, 2007 @05:03AM (#18359427) Homepage
    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 @06: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 tomstdenis (446163) <tomstdenis@@@gmail...com> on Thursday March 15, 2007 @06:45AM (#18359855) Homepage
      No. Answer? C gives you more control over the hardware which is required for something like an OS. It also has things like "pointers" required for memory mapped I/O.

      C++ ? Out of the question. Too many hidden operations make development a nightmare.
      Java? Are you even kiddin me? (yes, I know there are Java OSes, how those working out for you?)
      C#?..

      ooh ooh I know, Perl!!!

      If you want to reduce your bugs [in any language] simple steps

      1. Design code that you can verify and test
      2. Write modular code
      3. Re-use code as much as possible

      In this case, it seems the mbuf pointer gets changed before it's accessed later in the function. If they had tracked the life of that variable they would have spotted it. That type of error could have happened in any language.
      • by cyclop (780354)
        I have no formal CS education, nor I know low-level languages, so I naively ask: can you explain thoroughly what makes impossible/impractical for a high level language like Python or C# to be used for a kernel OS? It's sincere curiosity, not trolling or what. Thanks.
        • First, you need pointers. A pointer is basically a value which holds the address of something. While in a scripting language you can pass variables to functions/subroutines it isn't always by reference (e.g. a pointer). Pointers are also used when dealing with hardware which is mapped into the memory space. You need to be able to say "dump this data, exactly here in memory." Something you can't do with most scripting languages. It's also required to build things like page tables (process memory maps).
  • by badger.foo (447981) <peter@bsdly.net> on Thursday March 15, 2007 @06:53AM (#18359883) Homepage
    "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.
  • Forced release? (Score:5, Insightful)

    by Just Some Guy (3352) <kirk+slashdot@strauser.com> on Thursday March 15, 2007 @09:47AM (#18361099) Homepage Journal

    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.

  • by jnf (846084) on Thursday March 15, 2007 @12:44PM (#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.

"Don't discount flying pigs before you have good air defense." -- jvh@clinet.FI

Working...