Slashdot Mirror
Remote Exploit Discovered for OpenBSD
An anonymous reader writes "OpenBSD is known for its security policies, and for its boast of "only one remote exploit in over 10 years". Well, make that two, because Core Security has found a remotely exploitable buffer overflow in the OpenBSD kernel. Upgrade your firewalls as soon as possible."
"remote" in this case only means "not local." It does not, in any way, mean "far away," as the attacker has to be able to inject fragmented IPv6 packets, which is extremely hard to control (impossible?) from the other side of a layer 3 device.
LOL. So, then the OpenBSD team isn't part of the software industry?
t ures
Because, they've never come up with anything security wise:
http://en.wikipedia.org/wiki/OpenBSD_security_fea
Not at all.
No, IPv6 is enabled in the default install, though it does use only link-local addresses by default. This means that the attacker has to be on the same layer-2 network as the victim, but this is still classified as a remote exploit. Theo agreed, and the homepage has already been updated.
That could be. And don't get me wrong -- I'm a big OpenBSD fan and even have one of their posters framed and hanging in my home. But I think they could have handled this better. Given that security is their main selling point, I'd like to see the OpenBSD guys treat all buffer overflows as potentially exploitable. In this case, it appears that the fix to 3.9 and 4.0 branches was delayed for an extra week until Core produced a working remote root exploit. The problem with requiring a working exploit from bug reporters is that most of them lack the ability or inclination (or both) to produce one. This bug just happened to be reported by some of the best exploit writers in the world.
Also, even if the bug did only allow anyone to cause remote kernel panic on your OpenBSD firewall or server with a single packet, that is still a security vulnerability. They can call it a DoS vulnerability if they are sure one cannot lead to code execution.
-Fyodor
Your link does not once say that a denial of service effects the security of a system, in fact, by definition a denial of service denies access to the service, it does not compramise it. If the shit ain't being broken into, it's not a security issue, get a clue, read abook, take a class, or maybe reason shit out your own damn self using simple logic.
Sure. Look at the given text for the first google hit. It says "disneyification." This lead me to believe this term was referring to "pablum". So I looked that up, and found out that "pablum" is used to describe oversimplification of something.
Wikipedia has a good entry on Pablum.
Would you kindly mod me +1 insightful?
From the OPENBSD Website:
Only two remote holes in the default install, in more than 10 years!
At least they don't hide it.
It's very common. Many people also think OSX is based on Linux.
I'll even admit when I tried Linux for the first time ~1997, of the first "Linux distros" I tried was FreeBSD. I had no idea.
I don't always use unix-like operating systems; but when I do, I prefer FreeBSD.
From the bugtraq advisory:
From the OpenBSD CVS log:
So, who found the bug in the first place ?
- The kernel contains a lot of exploit mitigation stuff, that may well turn an arbitrary code execution into a DoS.
- OpenBSD doesn't actually include Sendmail or Apache, it includes forks of both. These are heavily audited by the OpenBSD guys, and not all of the changes are merged upstream.
When a new category of bug is found in OpenBSD, the entire tree is searched for occurrences of it. This often means that seemingly innocuous changes in something like OpenBSD's httpd turn out to have fixed things that are later found to be security holes.I am TheRaven on Soylent News
A remote kernel panic is a reliability issue - you can't exploit a paniced system! The OpenBSD team couldn't see a way to exploit the issue, Core subsequently proved that a panic could be avoided and exploit code executed, at which time it was upgraded to a security issue by the OpenBSD team. No conspiracy necessary.
I am TheRaven on Soylent News
No. Answer? C gives you more control over the hardware which is required for something like an OS. It also has things like "pointers" required for memory mapped I/O.
C++ ? Out of the question. Too many hidden operations make development a nightmare.
Java? Are you even kiddin me? (yes, I know there are Java OSes, how those working out for you?)
C#?..
ooh ooh I know, Perl!!!
If you want to reduce your bugs [in any language] simple steps
1. Design code that you can verify and test
2. Write modular code
3. Re-use code as much as possible
In this case, it seems the mbuf pointer gets changed before it's accessed later in the function. If they had tracked the life of that variable they would have spotted it. That type of error could have happened in any language.
Someday, I'll have a real sig.
"OpenBSD systems using default installations are vulnerable because the default pre-compiled kernel binary (GENERIC) has IPv6 enabled and OpenBSD's firewall does not filter inbound IPv6 packets in its default configuration."
- the default configuration on a fresh install actually has pf disabled (no two networks are exactly alike, and if you enable pf but do not supply your own rule set, a default rule set which passes dns, ssh and some icmp is enabled). Then again, any sane config with pf enabled will have "block all" as the default action and only pass inet6 if you are actually using inet6. This means that the vast majority of OpenBSD machines out there will have the equivalent of the advisory's block rule in their rule sets already.
"However, in order to exploit a vulnerable system an attacker needs to be able to inject fragmented IPv6 packets on the target system's local network. This requires direct physical/logical access to the target's local network -in which case the attacking system does not need to have a working IPv6 stack- or the ability to route or tunnel IPv6 packets to the target from a remote network."
This narrows the scope quite a bit.
Essentially the sky did not fall this time either, but I can see the OpenBSD developers taking another pass of "reading the code much like the devil reads the bible" over the ipv6 stack and the general neighborhood once again.
However, OpenBSD users have been instructed to update their systems already.
-- That grumpy BSD guy - http://bsdly.blogspot.com/
"Nowadays?" How long has it been since you've tried OpenBSD?
IPv6 has been enabled by default since v2.7 (June 2000), and fully supported by just about every included network program.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
The term "cover-up" implies that they did something outside of their usual process of classifying bugs & the attendant patches.
Except that they didn't; they classified it as a reliability issue (as they have done with many similar issues because they didn't see exploitability as of part of the problem ( Check out the history here: http://openbsd.org/errata40.html ; many kernel panic bugs going back several years are classified as "reliability" patches ). Once the proof-of-exploit was provided, they re-classified the existing patch in short order.
You can argue with their system of classification, but if you're actually administering an openbsd box, are you skipping the reliability patches because you like unreliable, but secure servers? I hope not...
In any case, that timeline leaves out the context of how the openBSD project actually works, which should be taken into consideration before implying accusations of "cover-up". In this case, I think that assessment is entirely unfair.
Have a look at singularity.
http://research.microsoft.com/os/singularity/
no comment
A quick search turns up this from just last May:
http://www.frsirt.com/english/advisories/2006/191
Do not anger the worm.
If the team were as security conscious as you claim, they wouldn't have simply dismissed it and would have given the issue more serious consideration.
They didn't simply dismiss it. They fixed the bug. At that point the question of how severe the vulnerability is only affects how critical getting the patch for the bug is. Being security conscious, they don't want to push out a patch without sufficient testing -- possibly causing new vulnerabilities -- unless they have to. When shown that the issue was in fact a remote exploit, they did not dismiss the issue then either, they upgraded the status of the issue and marked the patch as urgent.
All of this is perfectly consistent with security consciousness.
A team which does not take security seriously would have denied that there was a bug at all, would not have the fix, and would have found a way to claim that despite being shown exploit code for a remote vulnerability, it wasn't in fact a big deal. But that isn't what happened.
I've always thought of the BSDs (Net and Open anyway) as a smaller attack vector, nothing inherently more secure. They don't have a monopoly on smart developers and all humans make mistakes.
It is foolish to think that because all humans make mistakes, all humans make the same number and severity of mistakes, and have the same methods of identifying and correcting mistakes. For the same reason, it is foolish to think that because all software has bugs, that all software is equally buggy and the bugs are of equal severity. It is the attention payed to security, the methodologies of writing secure code, that help prevent bugs and make code that is truly inherently more secure.
OpenBSD gets a lot of scrutiny in the security world exactly for the reason that people deploy it because of its security. It may be a smaller attack vector due to market share, and due to it being harder to crack than what your typical army of script kiddies can handle. This does not mean it is not thoroughly poked and prodded by experts, nor does it mean that inherently superior security is an illusion.
The enemies of Democracy are
From:
http://marc.info/?l=openbsd-misc&m=117404837006368 &w=2
List: openbsd-misc
Subject: Re: Important OpenBSD errata
From: Theo de Raadt
Date: 2007-03-16 11:40:54
Message-ID: 200703161140.l2GBesJD020460 () cvs ! openbsd ! org
> This is idiotic, a big hole was found and the devs pissed about
> because they didn't want to admit it.
Noone in OpenBSD is pissed off about this. We posted the bug fix as
soon as we became aware of the problem. The timeline goes like this:
1) We were told there was a mbuf crash, which could remotely CRASH
the machine. There was no proof that more could be done, not even
a whiff.
2) We commited the fix, about 24 hours later. It took a few days to
get the errata up because the people who do that were at a conference.
It was labelled as a RELIABILITY FIX because everyone felt it was just
a CRASH. I then entered into a long conversation with Core explaining
why we label crash fixes (even remote) as RELIABILITY FIXES.
3) Core felt maybe something more could be done and continued working,
and ONE WEEK LATER later, finally managed to show us brand new code
which showed that intrusion was possible. Before that moment, it
was still just confirmed to be a CRASH.
4) A few hours after we become aware that it was more than a CRASH, we
changed the advisory to say it was a real security risk. We first had
to get the patch into -stable,
I changed index.html to talk about there being TWO remote holes in
more than 10 years, without even discussing this with any other
developer, because I knew it was true. Other developers in the group
were stunned to see me change it.
5) Core decided that their advisory should include their interpretation
of our discussion as to why OpenBSD labels crash fixes as RELIABILITY
FIXES. Three times I told them that I thought that was a mistake,
and that the public would not understand the reasoning as they wrote
it.
That is what happened. If you don't believe me, mail Ivan Arce at
Core and ask him if any of the 5 points above are wrong. Come on, go
ask him if I am a liar... go ahead.
Yes, some of the press got it wrong too, and part of that I feel is
Ivan Arce's fault. He should have been more cautious at explaining
the complex discussion OpenBSD had with Core, where we explained why
we label errata for remote crashes a Reliability Fix. Or he should
have skipped it altogether.
He even went around telling the press that this shows that IPV6 is a
risky new technology, when the fact is that this was a mbuf corruption
bug, in code that all parts of the network stack could potentially use
in the same way. He's got his layers wrong. But finding bugs in
other people's software lets companies like Core sell themselves as
experts. They are experts, but the good press they get should not
cost us in this way.
Let's see... the fsck_ffs fix pedro commited a few hours ago. That
fixes a serious problem where fsck fails to spot filesystem
corruption. Should we spend time fully assessing how rare or common
this situation is, and then errata it up the stream as fast as
possible, maybe even consider if there are security risks from such
filesystem corruption? Come on. Yet that is what some non-experts
moan for. They want projects with only a few people (who are doing
this for a hobby) to struggle down these well-defined p
There's an informative message from OpenBSD project leader Theo de Raadt outlining the timeline. Excerpt:
Core Security certainly deserves credit for finding this. Their advisory and de Raadt's timeline, however, give rather different impressions. Perhaps reading both will give a more complete picture.
No, not "any" exploit, but people who know what they do can still exploit it so why does it matter?
Also (atleast a few years ago) I've got the impression there are patches for Linux which does the same + more, and what about say trusted Solaris or similair? Are OpenBSD really better than those? Sure it might be a little more secure / security advanced than say FreeBSD for example, but I would still rather run FreeBSD for other reasons.