| |||||||||||||
A second remote hole for OpenBSDA second remote hole for OpenBSDPosted Mar 14, 2007 21:23 UTC (Wed) by ajross (subscriber, #4563)In reply to: A second remote hole for OpenBSD by drag Parent article: A second remote hole for OpenBSD
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?
(Log in to post comments)
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.
""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/14713/
http://secunia.com/advisories/16406/
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] 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] 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] 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.
|
|||||||||||||