How not to respond to a security advisory

OpenBSD exposes its inconsistencies

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