A second remote hole for OpenBSD [LWN.net]

A second remote hole for OpenBSD

Posted Mar 15, 2007 6:55 UTC (Thu) by bluefoxicy (guest, #25366)
Parent article: A second remote hole for OpenBSD

Ubuntu should follow the same behavior as OpenBSD in this respect. Considering Ubuntu has no open ports in the default install (perhaps Avahi now), the only possible remote holes involve kernel-level networking stack exploits. These do not occur very often, even in Linux.

I count OpenBSD's marketing as hand-waving because of this. If there's only one thing for you to knock (the network stack), then there's only one place holes can occur, and thus exposure comes out pretty low.

Now if OpenBSD loaded with SSH + Avahi + RPC + NFS, maybe I'd be impressed; give me remote holes in an enterprise server install involving a baseline of Apache, MySQL, FTP, and SSH. Consider that OpenBSD implements some subset of the PaX functionality (i.e. a partial NX emulation on 32-bit, similar to ExecShield; but no NX policy like PaX mprotect() or SELinux exec* permissions) and some similar but different protections (per-mmap() and per-malloc() randomizations instead of per-execution randomization); as well as full stack smash protection and a security-enhanced memory allocator. They should really be bragging about not having remote holes in code that's exploitable on OTHER platforms.

(Log in to post comments)

A second remote hole for OpenBSD

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

I believe OpenBSD does enable RPC by default. At least it did at some point in its history and did not incur any holes. I find this impressive myself.

But I think the "no default remote holes" is really trying to draw attention to two different things. OpenBSD has good engineering in the security department and tends to avoid compromises and exploits. We are all aware of this aspect of it, though some feel this sloganing is not very indicitave of that fact. But I think it is _also_ drawing attention to the conservative installation policy. Perhaps we are ignoring this aspect because the limitation of exposure is now the default thinking across most Linux variants and most Unix admins, but I can assure you it was not 10 years ago.

In other words, it may be that this slogan has simply gotten a bit out of date in that most unixes no longer foolishly turn on all kinds of services open to the world. Or at least most Free unixes.

A second remote hole for OpenBSD

Posted Mar 16, 2007 7:32 UTC (Fri) by bluefoxicy (guest, #25366) [Link]

Fedora.

it's just a beta

Posted Mar 16, 2007 23:39 UTC (Fri) by gvy (guest, #11981) [Link]

> Fedora
One should know he's in er... testbed when one installs Fedora. Consider bringing up IPv6 by default, which is even worse a security setup/maintenance nightmare than I would have though night before.

There are more OpenBSD-like Linux distros like Owl and ALT, where basesystem is additionally audited and tools like control(8) are in place to facilitate retaining admin-specified permissions on potentionally privileged binaries -- like "public/wheel/wheelonly/restricted" for su(8). Those that wouldn't crash-dive into 2.6 kernels and apache 2.0 when that would really be too much grief for reasonable sysadmins.

Disclaimer: I participate in this spring's ALTLinux release, as usual, but have long disliked RHL and Fedora for practical reasons (with much respect to Red Hat, of course).