A second remote hole for OpenBSD
Posted Mar 15, 2007 6:55 UTC (Thu) by bluefoxicy
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.
to post comments)