Linked by Thom Holwerda on Thu 21st Jan 2010 19:24 UTC, submitted by Anonymous
OpenBSD "OpenBSD is widely touted as being 'secure by default', something often mentioned by OpenBSD advocates as an example of the security focused approach the OpenBSD project takes. Secure by default refers to the fact that the base system has been audited and considered to be free of vulnerabilities, and that only the minimal services are running by default. This approach has worked well; indeed, leading to 'Only two remote holes in the default install, in a heck of a long time!'. This is a common sense approach, and a secure default configuration should be expected of all operating systems upon an initial install. An argument often made by proponents of OpenBSD is the extensive code auditing performed on the base system to make sure no vulnerabilities are present. The goal is to produce quality code as most vulnerabilities are caused by errors in the source code. This a noble approach, and it has worked well for the OpenBSD project, with the base system having considerably less vulnerabilities than many other operating systems. Used as an indicator to gauge the security of OpenBSD however, it is worthless."
Thread beginning with comment 405502
To view parent comment, click here.
To read all comments associated with this story, please click here.
Mark Williamson
Member since:

"mmap at 0" - does this mean being able to map physical address 0 (which would be bad), or simply "use mmap as memory allocation" (which I can't see a reason to disallow)?

For compatibility with various other OS ABIs, Linux *can* allow userspace processes to mmap stuff at virtual address zero which would otherwise usually be left unmapped IIRC. There's a knob in /proc/sys, I think, that lets you control whether this is allowed.

But there was some peculiar interaction whereby this knob wasn't used on RHEL systems systems where SELinux was enabled. RHEL's SELinux itself *could* enforce the same constraint if configured in policy but if it was missing from the policy then the constraint ended up not being enforced at all. Or something like that. This might be RHEL-specific.

Source (which has links to further details and details of the folks who worked on tracking down the security problems - Brad Spengler, Tavis Ormandy and Julien Tinnes):
Specific details on the RHEL problem: had a proper article about this stuff as well but I can't find it.

Disclaimer: This is probably a hopelessly mangled explanation since I only half remember it :-S

Reply Parent Score: 2

allthatiswrong Member since:

It was an error in policy, that was a deliberate decision to allow WINE to function, among other things.

It should not be considered an actual vulnerability in the framework.

Reply Parent Score: 1

f0dder Member since:

OK, so "just" virtual#0... would've been pretty bad if usermode processes could get arbitrary physical memory locations mapped.

Allowing to map virtual#0 is bad enough, though...

Disclaimer: This is probably a hopelessly mangled explanation since I only half remember it :-S
Nah, it was good enough, and the had the relevant links; the blog post, and it's links to involved kernel functions source code (nice feature!) it was pretty easy to understand.

All boils down to a bug in a C preprocessor macro causing sockop.sendpage function pointer to be uninitialized, and net/socket.c#sock_sendpage() missing a "if (unlikely(!sock->ops->sendpage))" check before calling.

Thanks for reminding me about this - I remember the exploit, but didn't check into the details; only knew that "local ring0 through socket-code bug" ;)

Reply Parent Score: 1