[aortega]

>can be backdoored[1] with the same ease

No, no with the same ease. Every OpenBSD commit is throughly reviewed, and there is only a bunch of commiters. Compared with linux, with thousands of commiters and tons of code added every day, OBSD is way more difficult to backdoor.

[gonzo]

> Every OpenBSD commit is throughly reviewed, [...]

You should observe that this didn't happen here.

Sam Leffler found that bug, fixed it, and sent OpenBSD the patch while bringing the "fast IPSec"stack to FreeBSD.

OpenBSD silently patched it.

The whole thing only came to light years later, when the accusations were made.

[aortega]

>You should observe that this didn't happen here.

I bet it now happens.

[symtos]

you bet? yet in your previous comment you stated it as a fact

[aortega]

yes.

[notaplumber]

No loadable kernel modules for OpenBSD either.

[tptacek]

Not having a formal kernel module system does not actually mean the kernel is secure. Exploits to create module loading systems out of kernel vulnerabilities are approximately as old as stack overflow exploits.

[notaplumber]

NX enforced kernel W^X, SMEP/SMAP, always-on stack protector and a limited attack surface (..say, from pledge(2)), only serve to make such theoretical attacks impractical against OpenBSD.

[tptacek]

No. Those are useful countermeasures, but kernel exploits for OpenBSD are neither theoretical nor impractical.

[nickpsecurity]

I'm glad you're saying it, too, as I get tired of this myth. I wrote a scheme on Schneier's blog for disproving it a while back. Basically, you counter the mitigations which look awfully similar to the one's that got countered in Linux and Windows. Once you have that, wait until a bug is mentioned on mailing list that can lead to memory attack. Weaponize it. Profit.

Leads me to what I claim is dirty secret behind "only 2 holes in..." claim they have: OpenBSD just fixes bugs they find without serious attempts to determine if they'd be exploitable vulnerabilities. They just do accounting differently than the rest. So, by their numbers, they only had 2 vulnerabilities because they didn't assess whether other bugs were vulnerabilities in the first place.

They have good code quality but they're full of shit about how vulnerable it is or isn't.

[ymse]

Note: they explicitly state "only two remote holes...", one of which can be found in this very thread.

Security problems are usually clearly marked in the changelog: http://www.openbsd.org/errata59.html

What really annoys me with OpenBSD is that users are expected to download the CVS source and compile it to fix problems rather than upgrade to a dot-release.

For a normal user that's fine, but if you have a bunch of servers you'll need a sophisticated build/deploy infrastructure to stay updated.

[JoachimSchipper]

Even as an OpenBSD fan, I'm not sure why tptacek was downvoted here. W^X etc. make it harder to write an exploit, but sufficiently-bad bugs can still yield arbitrary code execution. (Or confused-deputy problems allowing escalation to root, etc.; there's more than one way to pwn a box.)

And - architecturally - OpenBSD's kernel isn't that different from Linux, both being UNIX-style kernels; to the extent that OpenBSD's kernel has better security than Linux, it's mostly because OpenBSD tends to have fewer (and, sometimes, better-considered) features.

(There's an interesting argument to be had about Linux+grsecurity vs. OpenBSD - focusing on having some cutting-edge parts vs. solid engineering throughout - but that's not the argument we're having.)

[PhantomGremlin]

I'm not sure why tptacek was downvoted here

Maybe because his comment had the tone of:

"For this, I have found a truly wonderful proof, but the margin is too small to contain it."