How not to respond to a security advisory

OpenBSD exposes its inconsistencies

Protecting users from Firesheep and other Sidejacking attacks with SSL

Opinion A recently announced weakness in the BSD securelevel system isn't going to be fixed in OpenBSD. While securelevel may have problems, the vendor's security response is unacceptable and doesn't fit with its stated goals.

Recently, I stumbled across an interesting security advisory by RedTeam Pentesting, that discussed a vulnerability in a few implementations of the BSD securelevel system. There were two different issues, each affecting different implementations. As usual, I carefully read through the advisories trying to understand what sort of impact the vulnerabilities had, how disclosure had been done, and that sort of thing. Once I got to the "Fix" section of the advisory, something caught my eye immediately.

No fix will be released for OpenBSD. To quote Theo de Raadt: "Sorry, we are going to change nothing. Securelevels are useless."

I wouldn't have believed it to be an authentic vendor response had any other name been attached to the quote.

Secure what?

If you're a Linux or BSD user, you've probably heard of the securelevel system before. It's basically a configurable level of "security'' that changes the way in which the kernel handles certain system calls. The higher the securelevel, the more restrictive the kernel becomes. In BSD, you change the kernel securelevel by tuning a sysctl knob. On Linux, you echo the level to a file on a mounted sysfs file system. Once you're running at securelevel 1, you can no longer lower the securelevel without rebooting the system. Securelevel 2 is the highest possible level, at which point the kernel will be fairly restrictive with certain system calls.

I could probably talk about this for an entire article, but this is an opinion column. If you're interested in more about securelevels, have a look at the OpenBSD man page and this Sys Admin article.

It sounds pretty hokey - some magical knob that you can just "turn up'' for extra security. Worried about those hackers everyone is talking about? No problem, just activate "secure mode!'' Extra paranoid? Better turn it all the way up to "Highly Secure mode," and you'll be thwarting the bad guys left right and center. Right? Well, not exactly.

While the securelevel system certainly isn't useless, it does have some pretty big problems. Specifically, it was an afterthought developed to mitigate a design limitation in the Unix security model. Those of you who are really familiar with Unix system security will probably know what I'm talking about: the almighty root user.

In Unix, the root user has carte blanche. Once someone is root, there's no stopping them. The entire system is at their mercy, and the security model was never designed to limit root's access to the system to prevent them from doing something harmful. The intention of securelevels, however, is to help mitigate the effects of a root-level compromise.

How the problem works

In short, the vulnerability allows an attacker with root access to put arbitrary files on top of immutable files, allowing them to non-persistently replace them. According to the OpenBSD chflags(1) man page:

"An immutable file may not be changed, moved, or deleted."

Technically, the original file containing the immutable flag isn't changed; however, that distinction is nothing more than academic. The end result of exploitation is that immutable system files can be non-persistently replaced with any file an attacker chooses. Oops.

How not to respond to a security advisory

I think I say this in just about every one of my articles, but I'm going to say it again anyways. Vulnerabilities happen. The underlying reason for this vulnerability's existence is that Unix was never designed to prevent the root user from doing things like this. So what was the vendor response like? Aside from the fact that NetBSD wasn't affected by this issue, there isn't much good news.

No fix will be released for OpenBSD. To quote Theo de Raadt: "Sorry, we are going to change nothing. Securelevels are useless."

FreeBSD is still discussing the issue and no further response from the Linux maintainer has been received yet.

I'll quickly mention that I still firmly believe the Linux kernel developers need a central point of contact for security problems, but I don't want to go too far down that path again, at least not right now.

What it comes down to is this: OpenBSD's response is unacceptable. So securelevels are a hack. Fine. But why do they exist in OpenBSD if the developers won't maintain these securelevels and consider the system "useless?" And what business does an operating system that "prides itself on proactive security" have making such a callous remark about a security-related problem, however minor it is? NetBSD isn't vulnerable, and I doubt that implementing its solution (don't allow mounts at all at securelevel 2, unless they're just downgrading a file system to read-only) would be very difficult.

Here is a perfectly reasonable response that could have been used in place of what was offered.

"Due to inherent weaknesses with the securelevel system, securelevels will not be included in any future release of OpenBSD."

They could even be really nice and make some documentation changes to the securelevel(7) man page, complete with pull-ups to all of the supported security branches. This would at least warn people of the known limitations and weaknesses of the securelevel system, and it would fit very nicely under the "BUGS" section of the man page. At least from my perspective, that would seem like the right way to handle the problem.

If securelevels are as bad as Theo makes them out to be, removing the securelevel system from OpenBSD would be a great idea. There would be less code running in the kernel, and nobody would mistakenly use a security feature of the operating system that was, in the words of the developer, "useless". Besides, what's worse: no security, or a false sense of security?


One of the best things about OpenBSD is that it's a great operating system for new users to Unix. They're given a really solid default installation, and they don't have to know much about Unix or security to use the operating system effectively. Implying that securelevels are useless, when the limitations are not documented, and then still including the technology in the operating system seems really inconsistent with the goals of OpenBSD.

For those of you who are interested, there are plenty of other related technologies out there that are worth looking at. And while more complicated, many of them provide a much better solution to the problem of containing the almighty root. In the end, however, they're all just trying to fix a design limitation in Unix.

This article originally appeared in SecurityFocus.

Copyright © 2006, SecurityFocus

The next step in data security

More from The Register

next story
Israeli spies rebel over mass-snooping on innocent Palestinians
'Disciplinary treatment will be sharp and clear' vow spy-chiefs
Infosec geniuses hack a Canon PRINTER and install DOOM
Internet of Stuff securo-cockups strike yet again
'Speargun' program is fantasy, says cable operator
We just might notice if you cut our cables
Apple Pay is a tidy payday for Apple with 0.15% cut, sources say
Cupertino slurps 15 cents from every $100 purchase
YouTube, Amazon and Yahoo! caught in malvertising mess
Cisco says 'Kyle and Stan' attack is spreading through compromised ad networks
Hackers pop Brazil newspaper to root home routers
Step One: try default passwords. Step Two: Repeat Step One until success
Greater dev access to iOS 8 will put us AT RISK from HACKERS
Knocking holes in Apple's walled garden could backfire, says securo-chap
Microsoft to patch ASP.NET mess even if you don't
We know what's good for you, because we made the mess says Redmond
prev story


Providing a secure and efficient Helpdesk
A single remote control platform for user support is be key to providing an efficient helpdesk. Retain full control over the way in which screen and keystroke data is transmitted.
Saudi Petroleum chooses Tegile storage solution
A storage solution that addresses company growth and performance for business-critical applications of caseware archive and search along with other key operational systems.
Security and trust: The backbone of doing business over the internet
Explores the current state of website security and the contributions Symantec is making to help organizations protect critical data and build trust with customers.
Reg Reader Research: SaaS based Email and Office Productivity Tools
Read this Reg reader report which provides advice and guidance for SMBs towards the use of SaaS based email and Office productivity tools.
Security for virtualized datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.