LWN.net Logo

A second remote hole for OpenBSD

A second remote hole for OpenBSD

Posted Mar 14, 2007 20:57 UTC (Wed) by drag (subscriber, #31333)
In reply to: A second remote hole for OpenBSD by ajross
Parent article: A second remote hole for OpenBSD

"""Does anyone track this stuff on the Linux side?"""

Ya sure.

And when OpenBSD say 'default install' I take it to mean all the officially supported software. Not just the default configuration they happen to ship out. This is the software that they take most seriously with audits and such things. They tend to be very serious about this sort of thing.

And that's not just 'oh how it comes from the cdrom', but it's firewall stuff and there are a few more services then just sshd that OBSD provides by default. If I remember correctly.

This is opposed to any vunerabiltiies in their 'ports' system, which contains the information nessicary to install various non-core software packages. The ports system is not considured part of the 'default install'.

Out of ports there are varying degrees of seriousness and auditing. Apache is a good example of something they take seriously as their Apache versions is modified a bit, they havent' moved to the 2.0 code base yet. It's been extremely audited and their modifications are to increase security and such.

Their version of Apache has had a small number of holes in it, but it's nothing compared to what you have with the sort of Apache software that a typical Linux distribution ships.

The Linux distributions that come close are going to be things like Slackware and Debian Stable that only ship very well-used Apache versions based on the 1.3.x code base. (and Of course Debian being Debian has Apache2 aviable)

OpenBSD realy is a very impressive peice of work. It's the one system I would feel comfortable throwing out on the internet with no firewall or anything else to monitor and just let it sit serving web pages with only occasional updates.

Of course it's I/O performance is shit, it's SMP support is primative, and the userfreindliness is a throw back to the late 80's.

But you can't have everything, can you?

I mentioned Secunia in my last post. They are only one of dozens of places you can access vunerability databases, but they have a nicer interface which makes it usefull for showing links to.

Keep in mind that, like I mentioned before, it's easy to get into number matching games with Secunia so keep a critical eye on the sorts of vunerabilities.

Comparing remote holes is probably somewhat reliable though.

So you asked about remote holes on the Linux kernel.

http://secunia.com/product/2719/?task=statistics

There are 114 advisories on the Linux 2.6.x series kernel. Out of those about 19% are remote.
16% are unpatched.
2% will lead to system access, while 45% are DOS (usually crashes).

However keep in mind that something may be a 'DOS' now, can be a exploit later.

Also some advisories have multiple vunerabilities. So you can have a advisory that has 3-4 or more different bugs in it. They were just reported from a bunch.

But doing a quick overview of the situation shows that you have about 3 bugs that are repoted to allow remote access with the Linux 2.6 kernel from 2003 to 2007.

Looks like the same vunerabilities were present in 2.4 kernel also.

Now if you want a more serious look I suggest checking out OSVDB.
http://osvdb.org/

It's 'open source' not in the sort of software it tracks, but how it's completely open. Other places like Secunia or such allow a sort of overview access, but OSVBD has free access and a high level of quality.

It allows access to it's database directly and you can obtain copies of it.

So this would allow you to do fancy things like tie it into a security analysis tool so that when you find services on your network you can look up any vunerability information on them.

Or you can do a much more scientific data analysis of vunerabilities for doing more accurate comparisions.

Also they have rss feeds and I beleive you can set it up to retreive email notifications on various software packages.

Another important information they provide is vendor information, like contact information (which can be suprisingly hard to find sometimes).


(Log in to post comments)

A second remote hole for OpenBSD

Posted Mar 14, 2007 21:23 UTC (Wed) by ajross (subscriber, #4563) [Link]

Obviously this is turning into a Linux vs. BSD flame war, which has little to nothing to do with my original point of "Is OpenBSD's marketing slogan helping or huirting?". So this will be my last post. But it strikes me that this is a rather good meta-example of why silly marketing is a Bad Thing. Rather than argue about actual security flaws, or potential problems with the OpenBSD development process, we get sidetracked by OpenBSD fans into a "Linux is so much worse!" flame.

when OpenBSD say 'default install' I take it to mean all the officially supported software. Not just the default configuration they happen to ship out.

I think you've been hoodwinked. Granted, I can't find clear definitions of "remote hole" or "default install" on their website (another reason this kind of marketing gimmick is dumb). But I strongly suspect that "default install" means the software you get when you install the operating system using the default settings. Any other interpretation seems, to me, to be overly generous (and potentially insecure), no?

There are 114 advisories on the Linux 2.6.x series kernel. Out of those about 19% are remote. 16% are unpatched. 2% will lead to system access, while 45% are DOS (usually crashes).

OK, I call your bluff. I just looked at these in the expanded list of these vulnerabilities (not the pie charts -- the actual list). And I couldn't find any of them that fit the OpenBSD definition of a "remote hole" (i.e. code execution, not DoS) in the "default install" of a major Linux distribution. There were plenty of local issues, to be sure, and lots of DoS opportunities. And I saw a few remotely exploitable holes or "security bypass" bugs, but only in little-used code that (as far as I am aware) major vendors don't ship enabled.

So as far as I can see, the "OpenBSD N" value for the linux kernel over the lifetime of the Secunia database is in fact, zero, which I amusingly note is somewhat less that two. Did I miss something?

A second remote hole for OpenBSD

Posted Mar 14, 2007 22:22 UTC (Wed) by drag (subscriber, #31333) [Link]

"""Obviously this is turning into a Linux vs. BSD flame war,"""

If you say so. It seemed very civil to me so far.

""Rather than argue about actual security flaws, or potential problems with the OpenBSD development process, we get sidetracked by OpenBSD fans into a "Linux is so much worse!" flame.""

I mentioned quite a few times things related to OpenBSD's development proccess. (code auditing, etc)

My ultimate point in all of this is that yes saying 'N holes' is usually misleading, but in this case it's not. It's just a one liner, if you want to pick it appart you can, but its still mostly valid and is actually pretty good.

You and I both know that pretty much any Linux distribution, if you take a ten year history look at it, will show much more then 2 remote holes.

This does not stop me from prefering Linux distributions over OpenBSD though. It's not enough for me that a release has to be secure, it has to actually usefull... which generally OpenBSD is not for the stuff I want.
(I expect most OBSD fanboys actually prefer to use Windows or OS X for their day to day desktop OS)

""OK, I call your bluff. I just looked at these in the expanded list of these vulnerabilities (not the pie charts -- the actual list). And I couldn't find any of them that fit the OpenBSD definition of a "remote hole" (i.e. code execution, not DoS) in the "default install" of a major Linux distribution. There were plenty of local issues, to be sure, and lots of DoS opportunities. And I saw a few remotely exploitable holes or "security bypass" bugs, but only in little-used code that (as far as I am aware) major vendors don't ship enabled.""

Well first off your the one that said that only Kernel vunerabilities and Sshd vunerabilities count. So I am just responding to your own restrictions you put on this discussion. Of course this is rather bizzare since OpenBSD does a lot more then just have a kernel and a remote shell, but whatever you want.

The three vunerabilities, which is just the kernel I mentioned are:
http://secunia.com/advisories/13232/
Problems with SMBFS that can possibly lead to remote code execution.

http://secunia.com/advisories/14713/
Bluetooth vunerability leading to root access. Trivially exploitable.

http://secunia.com/advisories/16406/
"xdr_xcode_array2()" error allows remote access via NFSACL.

They aren't hugely serious. Linux kernel itself is pretty nice.

A second remote hole for OpenBSD

Posted Mar 15, 2007 0:32 UTC (Thu) by ajross (subscriber, #4563) [Link]

I know I promised not to post again. But now you're starting to post explicit misinformation. Please be careful to get things correct.

Maybe you amisinterpreted the argument I was making? The point here is to judge the Linux kernel by the same standard as OpenBSD uses for their (IMHO) ridiculous slogan, not to enumerate other (obviously important) kinds of flaws, and not for the purpose of flaming about platforms, but as an exercise to show use useless a metric "Only N holes" is.

http://secunia.com/advisories/13232/[1]
Problems with SMBFS that can possibly lead to remote code execution.

From the description: "Multiple vulnerabilities have been reported in the Linux Kernel, which potentially can be exploited by malicious, local users to ...". How exactly does this qualify as a "remote hole?" OpenBSD's metric is specifically about network-exploitable vulnerabilities, not local root exploits.

http://secunia.com/advisories/14713/[2]
Bluetooth vunerability leading to root access. Trivially exploitable.

This is another local vulnerabilty. It's clearly not a "remote hole". You can't compromise a system remotely via bluetooth; the bug is that you can achieve root locally by exploing a bug with the syscall handlers.

http://secunia.com/advisories/16406/[3]
"xdr_xcode_array2()" error allows remote access via NFSACL.

This was never verified as anything but a DoS, so by OpenBSD's own standards (silly ones, of course, which is my whole point) it doesn't count. The bug in the OpenBSD IPv6 code was not termed a remote hole until someone wrote an exploit, so clearly it's not fair to tag Linux with a different standard.

I'm sorry, but every one of those vulnerabilities would be rejected by the OpenBSD team as part of their "Only N holes" metric. Are you starting to agree with me now that it's perhaps not as informative a slogan as you might have originally thought?

A second remote hole for OpenBSD

Posted Mar 15, 2007 1:03 UTC (Thu) by drag (subscriber, #31333) [Link]

Oh, ok. :)

(see? It is possible to have a rational discussion.)

A second remote hole for OpenBSD

Posted Mar 15, 2007 3:52 UTC (Thu) by tetromino (subscriber, #33846) [Link]

IMHO, you have misinterpreted the advisories.

http://secunia.com/advisories/13232/[1] refers to the first part of the advisory (note the [1]), which is a true remote exploit:

"Stefan Esser has reported multiple vulnerabilities within the smb filesystem (smbfs) implementation that are caused due to various types of errors when handling server responses.

Successful exploitation requires that a malicious person has control over a smb server or is able to intercept and manipulate traffic."

The "local users" refers to the second part of the advisory (the unix_dgram_recvmsg() issue). For some reason, Secunia's summary blurb only describes the second part. Go figure.

http://secunia.com/advisories/14713/[2]

"A signedness error in the "bluez_sock_create()" function when creating bluetooth sockets can potentially be exploited to gain root privileges on a vulnerable system."

If I'm reading this right, a malicious user can take over a server by crafting malicious bluetooth packets, in other words, that's a remote root. (Remember, bluetooth devices can be very long-range: http://www.smallnetbuilder.com/content/view/24256/98/)

A second remote hole for OpenBSD

Posted Mar 15, 2007 16:17 UTC (Thu) by bronson (subscriber, #4806) [Link]

Because OpenBSD ships with neither SMBFS nor Bluetooth enabled by default, these remote holes would not count against it. Therefore, they should not count against Linux. As ajross was saying, you need to compare apples to apples.

Personally, I think pretty much any measurement against OpenBSD's default install is meaningless. Nobody runs it! "Only 12 remote holes in a fully-provisioned OpenBSD LAMP setup!" would be a much better statistic.

A second remote hole for OpenBSD

Posted Mar 15, 2007 14:10 UTC (Thu) by jond (subscriber, #37669) [Link]

Well first off your the one that said that only Kernel vunerabilities and Sshd vunerabilities count. So I am just responding to your own restrictions you put on this discussion.
That's my interpretation of their slogan too. I'm pretty confident its what they actually mean: I think I may have got that from an OpenBSD talk I went to once.

A second remote hole for OpenBSD

Posted Mar 15, 2007 22:53 UTC (Thu) by roskegg (subscriber, #105) [Link]

From the mouth of Theo himself at various live appearances, the remote hole thing is based on default install with default configuration. If you enable any service in the base system that is not enabled in the default configuration, it is not counted toward the remote hole count.

A second remote hole for OpenBSD

Posted Mar 14, 2007 23:09 UTC (Wed) by akumria (subscriber, #7773) [Link]

And when OpenBSD say 'default install' I take it to mean all the officially supported software. Not just the default configuration they happen to ship out. This is the software that they take most seriously with audits and such things. They tend to be very serious about this sort of thing.

That's what you take it to mean but a lot of people, including me, take "default install" to mean the OpenBSD kernel and OpenSSH.

I'd say that for those two components the number of times the "default install" has been remotely compromised would be very similiar on most *BSDs and Linux. Especially as everyone is using OpenSSH.

A second remote hole for OpenBSD

Posted Mar 15, 2007 4:45 UTC (Thu) by k8to (subscriber, #15413) [Link]

For the record, OpenBSD does enable a few more things, like portmap, by default. So the list is *a bit* longer than that, but not much.

A second remote hole for OpenBSD

Posted Mar 16, 2007 8:25 UTC (Fri) by miod (guest, #41457) [Link]

Actually, portmap has been disabled by default since a fair number of OpenBSD releases already.

A second remote hole for OpenBSD

Posted Mar 16, 2007 15:03 UTC (Fri) by k8to (subscriber, #15413) [Link]

Just goes to show.......

Um. So uh, I guess my OpenBSD usage is a bit dated.

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds