Feeds

How not to respond to a security advisory

OpenBSD exposes its inconsistencies

Intelligent flash storage arrays

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

Intelligent flash storage arrays

More from The Register

next story
You really need to do some tech support for Aunty Agnes
Free anti-virus software, expires, stops updating and p0wns the world
Attack reveals 81 percent of Tor users but admins call for calm
Cisco Netflow a handy tool for cheapskate attackers
Privacy bods offer GOV SPY VICTIMS a FREE SPYWARE SNIFFER
Looks for gov malware that evades most antivirus
Patch NOW! Microsoft slings emergency bug fix at Windows admins
Vulnerability promotes lusers to domain overlords ... oops
Oi, Europe! Tell US feds to GTFO of our servers, say Microsoft and pals
By writing a really angry letter about how it's harming our cloud business, ta
prev story

Whitepapers

Why and how to choose the right cloud vendor
The benefits of cloud-based storage in your processes. Eliminate onsite, disk-based backup and archiving in favor of cloud-based data protection.
Forging a new future with identity relationship management
Learn about ForgeRock's next generation IRM platform and how it is designed to empower CEOS's and enterprises to engage with consumers.
High Performance for All
While HPC is not new, it has traditionally been seen as a specialist area – is it now geared up to meet more mainstream requirements?
Protecting users from Firesheep and other Sidejacking attacks with SSL
Discussing the vulnerabilities inherent in Wi-Fi networks, and how using TLS/SSL for your entire site will assure security.
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.