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
| 