Feeds

How not to respond to a security advisory

OpenBSD exposes its inconsistencies

The essential guide to IT transformation

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?

Conclusion

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

Next gen security for virtualised datacentres

More from The Register

next story
e-Borders fiasco: Brits stung for £224m after US IT giant sues UK govt
Defeat to Raytheon branded 'catastrophic result'
Germany 'accidentally' snooped on John Kerry and Hillary Clinton
Dragnet surveillance picks up EVERYTHING, USA, m'kay?
Snowden on NSA's MonsterMind TERROR: It may trigger cyberwar
Plus: Syria's internet going down? That was a US cock-up
Who needs hackers? 'Password1' opens a third of all biz doors
GPU-powered pen test yields more bad news about defences and passwords
Think crypto hides you from spooks on Facebook? THINK AGAIN
Traffic fingerprints reveal all, say boffins
Rupert Murdoch says Google is worse than the NSA
Mr Burns vs. The Chocolate Factory, round three!
Microsoft cries UNINSTALL in the wake of Blue Screens of Death™
Cache crash causes contained choloric calamity
prev story

Whitepapers

5 things you didn’t know about cloud backup
IT departments are embracing cloud backup, but there’s a lot you need to know before choosing a service provider. Learn all the critical things you need to know.
Implementing global e-invoicing with guaranteed legal certainty
Explaining the role local tax compliance plays in successful supply chain management and e-business and how leading global brands are addressing this.
Build a business case: developing custom apps
Learn how to maximize the value of custom applications by accelerating and simplifying their development.
Rethinking backup and recovery in the modern data center
Combining intelligence, operational analytics, and automation to enable efficient, data-driven IT organizations using the HP ABR approach.
Next gen security for virtualised datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.