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 405494
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[6]: Author of the article here
by f0dder on Fri 22nd Jan 2010 17:49 UTC in reply to "RE[5]: Author of the article here"
f0dder
Member since:
2009-08-05

"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)?

Reply Parent Score: 1

Mark Williamson Member since:
2005-07-06

"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):
http://lwn.net/Articles/349999/
Specific details on the RHEL problem:
http://kbase.redhat.com/faq/docs/DOC-18042

lwn.net 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:
2010-01-22

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.

http://eparis.livejournal.com/606.html

Reply Parent Score: 1

f0dder Member since:
2009-08-05

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 lwn.net had the relevant links; the cr0.org 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