Slashdot Mirror
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."
freakin rare event, hell must have frozen over! /me takes a snapshot of the moment and feels badly for all the BSD-folk
C|N>K
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...
for sale
I'm a self-modifying sig virus
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.
I think they just found the Windows2003 Server Emulator.
* 2007-02-20: First notification sent by Core.
/I kid I kid
* 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'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:
-Fyodor
Insecure.Org
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.
"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.
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.
Thank GOD I run the company webserver on NT!
Amiga : ZERO exploits !! About as many users !!
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.
With reasonable men I will reason; with humane men I will plead; but to tyrants I will give no quarter. -- William Lloyd
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 has already been updated.
An IP for everyone. Bah!
why, That's Communism!
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.
-The Sox won the world series
-The Pope died
-Mac got Intel chips
-The Berlin Wall came down
-I out-lived 4 cats
-Man walked on the moon
-I got laid
and...
-BSD had a hole
From the OPENBSD Website:
Only two remote holes in the default install, in more than 10 years!
At least they don't hide it.
Fortunately, that bug has been fixed before the OpenBSD 4.1 CDs were sent to the press.
{{.sig}}
...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):
I am NaN
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).
= 18191856
Can we please stop using C?
http://it.slashdot.org/comments.pl?sid=224594&cid
I am TheRaven on Soylent News
"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.
-- That grumpy BSD guy - http://bsdly.blogspot.com/
"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.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
FTFA:
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.
Dewey, what part of this looks like authorities should be involved?
First, there has to be a lot of low-level code just to be able to boot most modern computers. Any high-level, non-native language (Python, Perl, C#, etc) need to have an OS to run their VM. Anything low-level, such as disk access, memory management, process management, etc, requires more-or-less direct access to the hardware. This means assembly, in many cases.
.Net framework, and most other popular languages. And it's easier to take advantage of a Perl or Python or .Net exploit when you find them, as you don't need intimate knowledge of the underlying architecture.
Fully-native object oriented languages like Objective-C are no better than C for security. In fact, they bring their own set of baggage with them. Hybrid ("half-assed") object languages like C++ are worst of all, as they unite the simplicity of Brainfuck with the inherent security of C and the speed of Perl. (Drawbacks of C++ exaggerated for comic effect. If you are a C++ weenie, please don't take offense.)
When it comes down to it, for general-purpose operating systems, there's not been found a better way than the combination of ASM + C.
I think the issue is, where does the OS stop and the application space begin?
Does the whole TCP/IP stack *need* to be written in C? Probably not. Considering the amount of use it gets, it's probably a great place to optimize for performance, though, so writing it in C helps.
And I'm not convinced the problem is the language. The OpenBSD folks have written a good, solid OS in C, with very few exploits. I've seen exploits in Perl, Python, C#, the
As usual, the debate is not as simple as, "C bad, everything else good."
Anyway, that's my rant, and I'm sticking to it.
Microsoft is to software what Budweiser is to beer.
Have a look at singularity.
http://research.microsoft.com/os/singularity/
no comment
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.
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.
There's an informative message from OpenBSD project leader Theo de Raadt outlining the timeline. Excerpt:
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.