Feeds

How not to respond to a security advisory

OpenBSD exposes its inconsistencies

Securing Web Applications Made Simple and Scalable

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

Mobile application security vulnerability report

More from The Register

next story
HIDDEN packet sniffer spy tech in MILLIONS of iPhones, iPads – expert
Don't panic though – Apple's backdoor is not wide open to all, guru tells us
LibreSSL RNG bug fix: What's all the forking fuss about, ask devs
Blow to bit-spitter 'tis but a flesh wound, claim team
NEW, SINISTER web tracking tech fingerprints your computer by making it draw
Have you been on YouPorn lately, perhaps? White House website?
Manic malware Mayhem spreads through Linux, FreeBSD web servers
And how Google could cripple infection rate in a second
NUDE SNAPS AGENCY: NSA bods love 'showing off your saucy selfies'
Swapping other people's sexts is a fringe benefit, says Snowden
Own a Cisco modem or wireless gateway? It might be owned by someone else, too
Remote code exec in HTTP server hands kit to bad guys
British data cops: We need greater powers and more money
You want data butt kicking, we need bigger boots - ICO
prev story

Whitepapers

Reducing security risks from open source software
Follow a few strategies and your organization can gain the full benefits of open source and the cloud without compromising the security of your applications.
Consolidation: The Foundation for IT Business Transformation
In this whitepaper learn how effective consolidation of IT and business resources can enable multiple, meaningful business benefits.
Application security programs and practises
Follow a few strategies and your organization can gain the full benefits of open source and the cloud without compromising the security of your applications.
Boost IT visibility and business value
How building a great service catalog relieves pressure points and demonstrates the value of IT service management.
Consolidation: the foundation for IT and business transformation
In this whitepaper learn how effective consolidation of IT and business resources can enable multiple, meaningful business benefits.