# RootPrompt.org   Nothing but Unix.[Home] [Features] [Programming] [Mac OS X] [Search]


 Feature: Sniping at OpenBSD

Last week several vulnerabilities with OpenBSD were announced on the full disclosure list Bugtraq. That a hole was found and exploited is not an amazing thing. The amazing and impressive thing is how long OpenBSD had gone without a local root exploit.

There was a reaction to the announcements by the OpenBSD developer team about the exploits that surprised me. The reaction was to imply that the developers had been hiding the truth about the exploits so as to not tarnish the reputation of OpenBSD.

 (Submitted by Noel Mon Oct 9, 2000 )

  

Sniping at OpenBSD

noeld@rootprompt.org

Last week several vulnerabilities with OpenBSD were announced on the full disclosure list Bugtraq. That a hole was found and exploited is not an amazing thing. The amazing and impressive thing is how long OpenBSD had gone without a local root exploit.

There was a reaction to the announcements by the OpenBSD developer team about the exploits that surprised me. The reaction was to imply that the developers had been hiding the truth about the exploits so as to not tarnish the reputation of OpenBSD.

Just in case you think that I am a militant OpenBSD user defending the true faith, let me explain that I am a Linux user. I have played with OpenBSD and will most likely play with it again. I am not however, what you could call a member of the OpenBSD community. As I said I am a Linux user. I have been impressed with the work the OpenBSD team has done in proactivly finding bugs and the results they have gotten from this approach. I think that there is room in the world for Linux, *BSD, and even the commercial Unix variants. It is my belief there are advantages to having choices and using different approaches to solve common problems.

On the second of October an exploit to the chpass utility was discovered, the following day the OpenBSD team issued the following advisory.

----------------------------------------------------------------------------

OpenBSD Security Advisory

October 3, 2000

Format string vulnerability in libutil pw_error(3) function

----------------------------------------------------------------------------

SYNOPSIS

A format string vulnerability present in the pw_error() function of OpenBSD 2.7's libutil library can yield localhost users root access through the setuid /usr/bin/chpass utility. This particular vulnerability was repaired three months ago on June 30th in OpenBSD-current during a complete source tree audit for format string problems.

OpenBSD developers became aware of an exploit circulating for the chpass(1) program on the evening of October 2, 2000.

...

The entire OpenBSD Security Advisory

Some people saw the statement by the OpenBSD team that the bug had already been fixed as an attempt to save face about the exploit. Other people were angry that the team had fixed the bugs and had not made any announcement of the fix.

Here are some examples of these reactions in Bugtraq:

"What I would like to know is why this and a number of other privileged applications have security vulnerabilities in them. They WERE fixed, but NO ADVISORY nor ANY MENTION IN THEIR DAILY CHANGLOG!"

Email to Bugtraq

Todd Miller an OpenBSD developer responded to this question with the following:
"As one of the people who took part in the audit I can honestly say that we didn't think they *were* exploitable. There was no intention of hiding any fixes, we just went through the entire source tree (we did not target privileged programs specifically) and fixed format string problems where we found them and released patches for those we knew to be exploitable (like xlock)."

Todd Miller's reply

It is unfair to require perfection from OpenBSD and its developer team while not using the same yardstick for the rest of the world. Other operating systems can have multiple exploits a week or take six months to fix a problem without public accusations that they are trying to hide the problem. Without a doubt, sometimes they are.

I am hoping that this reaction is the result of misunderstanding rather than some other reason. In this article I attempt to explain the situation as I see it as an outsider to the OpenBSD community.

The key to understanding this is that the OpenBSD audit process does not look for exploits, they instead look for software bugs. Most of the time when an exploit comes out there is an already-fixed bug. In this event, the code was fixed in the current version of OpenBSD, but no patch had been released because prior to the second of October they did not know it was exploitable.

It is interesting to me that when a new root exploit comes out for any other operating system, people wonder when will it be fixed, or are amazed that there is a patch already available and suspect that the announcement was delayed. In one commercial Unix I have supported, statd was remotely exploitable for about six months before a patch was available. With OpenBSD, not only do they announce the exploit, but they do so with a patch in under twenty-four hours and have fixed the source months earlier.

This is not how people trying to hide their problems from the world act. These are not individuals acting out of pride. I am sure that the OpenBSD team would prefer that there was no exploit. But once one was out there, they acted quickly and professionally.

As for the question of why they did not make an announcement when they found the bug months ago, the answer is that they did not know it was exploitable. Theo de Raadt asked me in an email, "We fixed 800+ format string bugs. Should we release an advisory for each? Should we cry wolf? Or should we respond to the ones that we know are exploitable?"

If the OpenBSD team released a security advisory every time they found a bug, the advisories would become useless. They have fixed thousands of bugs, some of these were exploitable most were not. They have and continue to practice full disclosure. There is no fault to find with them not releasing an announcement for this bugfix before an exploit was discovered.

In an email to Bugtraq Theo de Raadt said:

"However, when we fix a couple hundred format string bugs, we do not post a patch for everyone of them. Nor do we do all that much thinking about which ones are going to be exploitable, since we don't write exploits, and also tend to be rather busy with a whole bunch of other stuff too."

entire message to Bugtraq

As with any good project they are looking at ways to improve how they work and communicate with their user community. Todd Miller an OpenBSD developer had this to say.

"While it doesn't make sense to release advisories for all these things, it would be sensible to release patches for those programs that run with elevated privileges. We're not in the business of creating exploits (heck, I wouldn't know where to start), but we can cover our collective butts (and those of our users) by releasing patches for things that _might_ be security related and letting others in the security community whack away at them look for exploitability.

In other words, we have a tendency to be proactive in our source tree and we need to export this into the patch process to better serve our users."

I would argue that rather than complain that the OpenBSD team is not perfect (not that they have claimed to be), we should look at the positive things they have done and continue to do. After all, their goal is to be number one in security and do they really have any competition? This is the same sort of problems that the Linux auditing projects are going to run into as they progress and we should hope that they progress to the point that we have this problem in the Linux community.

"In OpenBSD land, the pain is quick, at least." -- Theo de Raadt


Our content can be syndicated: Main page Mac Page

Copyright 1999-2005 Noel Davis. Noel also runs web sites about sailing and kayaking.
All trademarks are the property of their owners.
All articles are owned by their author