A second remote hole for OpenBSD
Posted Mar 14, 2007 22:22 UTC (Wed) by drag
In reply to: A second remote hole for OpenBSD
Parent article: A second remote hole for OpenBSD
"""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:
Problems with SMBFS that can possibly lead to remote code execution.
Bluetooth vunerability leading to root access. Trivially exploitable.
"xdr_xcode_array2()" error allows remote access via NFSACL.
They aren't hugely serious. Linux kernel itself is pretty nice.
to post comments)