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

Well done, the OpenBSD team.

[Anonymous Coward]

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.

Re:Well done, the OpenBSD team.

[Anonymous Coward]

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:Well done, the OpenBSD team.

[Kandenshi]

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.

Re:Well done, the OpenBSD team.

[drsmithy]

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

Re:Well done, the OpenBSD team.

[Richard_at_work]

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:Well done, the OpenBSD team.

[drsmithy]

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.

Re:Well done, the OpenBSD team.

[TheRaven64]

The thing is, it doesn't matter. The OpenBSD folk treat pretty much every bug as a security hole. I heard one of them say this, which I think should be taken to heart by all software developers:

The only difference between a bug and a security hole is the intelligence of the attacker. As such, the hole was patched when they thought it was just a DoS. All escalating it does is encourage admins not to actually apply the patches.

Re:Well done, the OpenBSD team.

[Just Some Guy]

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:Well done, the OpenBSD team.

[Chris Burke]

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, so you copy good practices even if they aren't going to earn you more money.

Though I think it is fairly simple to concoct a scenario where in the long term it does cost money not to adopt good practices -- such as losing marketshare because of security problems. Short sightedness is also a problem people who value only money often have, at least the ones running publicly traded corporations.

Re:Well done, the OpenBSD team.

[Just Some Guy]

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 directly financially profit from them.

Re:Advisory Timeline

[Secret Rabbit]

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.

They've earned a mulligan, I think

[peacefinder]

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

[jrockway]

> Availability is a key facet of security. There's no fuckin' point having a "secure" system which you can't even use.

Sure there is. Think, for example, of a data warehouse containing social security numbers. Would you prefer that that system go down entirely, or that the contents of the database is exposed. A system that detects trouble and shuts itself down until someone fixes it sounds good to me.

Also, by your standards, a power failure is a security hole. That's just not true.

Re:It's a feature

[TheRaven64]

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.

Re:Advisory Timeline

[TheRaven64]

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

Forced release?

[Just Some Guy]

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.

Languages don't kill people

[Tony]

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.

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

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.