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

Barely "remote"

[_iris]

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

Re:Barely "remote"

[pchan-]

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.

Re:Not in the default install

[dmiller]

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.

Re:It's a feature

[ArsenneLupin]

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:Advisory Timeline

[fv]

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

OpenBSD Website

[Anonymous Coward]

From the OPENBSD Website:
Only two remote holes in the default install, in more than 10 years!

At least they don't hide it.

Re:Well done, the OpenBSD team.

[TheRaven64]

Note that many Sendmail and Apache exploits do not affect OpenBSD, for two reasons:

1. The kernel contains a lot of exploit mitigation stuff, that may well turn an arbitrary code execution into a DoS.
2. OpenBSD doesn't actually include Sendmail or Apache, it includes forks of both. These are heavily audited by the OpenBSD guys, and not all of the changes are merged upstream.

When a new category of bug is found in OpenBSD, the entire tree is searched for occurrences of it. This often means that seemingly innocuous changes in something like OpenBSD's httpd turn out to have fixed things that are later found to be security holes.

Re:Can we now please stop using C?

[tomstdenis]

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.