Remote Exploit Discovered for OpenBSD

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

Comments

Some amusing interchanges b/t OpenBSD and CoreLabs

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

[fv]

I'm a bit surprised that the summary didn't mention the rather interesting timeline in the Core advisory, 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

Re:Advisory Timeline

[evilviper]

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?

Re:Advisory Timeline

[Sam H]

If a power failure can be triggered by an attacker and affects the availability of a resource you rely on, then yes, it's a security hole. Welcome to the real world.

Re:Advisory Timeline

[TheAwfulTruth]

The OpenBSD team is SUPPOSED to assume the worst case when no facts are known. They are supposed to investigate EVERY bug as being a potential exploit. Unlike Linux, it is not the external commuities responsibility to find and fix bugs, it is OpenBSDs. They are supposed to be providing a completly vetted and secure system. It's what makes them special.

At least they used to. Now they are like /everyone/ else, deny deny deny, till they get egg shoved in their face. Having an external company more vigilent about exploits in OpenBSD than OpenBSD itself is is disturbing. OpenBSD fails it this time.

And in fact it may be this type of internal behavior that has led to the existance of this bug in the first place. Rather than giving them a pass, they should be crucified for this. They need to be reminded that they cannot go slack or their entire reason for being will evaporate.

Doesn't matter how good a C programmer you are

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

Re:Doesn't matter how good a C programmer you are

[Fnordulicious]

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.

pablumfication

[vocaro]

Can anyone explain what pablumfication means? The only hit is the very same report. I thought maybe it was pablumification, but that only gets two more hits.

Re:pablumfication

[chenjeru]

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 instant baby cereal.

_The phrase 'pablum puking', when used in political speech, is used to describe one who seems to lack the ability to digest simple logic or common sense. For example, someone who holds forth the argument that children should be afforded the freedom to play in traffic could rightly be refered to as a 'pablum puking idiot'. ..thus, the poster's creation of the word in reference to oversimplification.

Fixed in OpenBSD 4.1

[chrysalis]

Fortunately, that bug has been fixed before the OpenBSD 4.1 CDs were sent to the press.

Wrong...

[Phil John]

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

Or, as a recent Ars article 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.

Not enabled = not default install

[Anonymous Coward]

"Default install" means "enabled by default". Look at the errata. For example:

# 001: SECURITY FIX: March 25, 2006 All architectures
A race condition has been reported to exist in the handling by sendmail of asynchronous signals. A remote attacker may be able to execute arbitrary code with the privileges of the user running sendmail, typically root. This is the second revision of this patch.

Since sendmail only listens on localhost doesn't affect slogan.

Not mention apache or bind, that must manually enabled.

Yeah, this makes the slogan a nonsense (and I use OpenBSD everyday and I really like it, every Internet faced system runs on it).

Re:WHOA WTF

[Curtman]

You Linux pups seem to think bugs are normal events.

When was the last time a remote root exploit was found in the Linux kernel?

Re:Well done, the OpenBSD team.

[golgotha007]

I'm curious about something.

Other than kernel 2.0.x (10+ years ago), has Linux ever had a kernel bug that was exploitable remotely?

Re:WHOA WTF

[Curtman]

there is a distribution that has a remote root exploit

Nope. I think you meant to say: Had a local root exploit.

Re:Well done, the OpenBSD team.

[hattmoward]

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 already have a fairly security-aware group using their software. But sometimes it's time for mommy to put you in the highchair and force-feed you. Some major security features added to Windows Vista are their attempt to do exactly that, though we'll leave the discussion on the merit of those features for another post.

There (probably) was one in November 2004

[tetromino]

See http://www.ubuntu.com/usn/usn-30-1; something like 7 vulnerabilities were found in the kernel's smbfs driver which could be used for remote DoS and potentially for remote root, at least on some configurations (the Linux community decided to fix the bugs instead of waiting for exploit code to appear). There may have been other remote root exploits since then -- I haven't been keeping track.

OpenBSD and the security myth

[jnf]

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.