Remote Exploit Discovered for OpenBSD 338
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."
WHOA WTF (Score:2, Funny)
Re: (Score:2)
Re:WHOA WTF (Score:4, Informative)
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.
Time to make a list... (Score:5, Funny)
-The Pope died
-Mac got Intel chips
-The Berlin Wall came down
-I out-lived 4 cats
-Man walked on the moon
-I got laid
and...
-BSD had a hole
Re:Time to make a list... (Score:5, Funny)
Re:WHOA WTF (Score:4, Interesting)
When was the last time a remote root exploit was found in the Linux kernel?
There (probably) was one in November 2004 (Score:4, Interesting)
Re: (Score:3, Interesting)
Nope. I think you meant to say: Had a local root exploit.
Re:WHOA WTF (Score:4, Funny)
Heh (Score:5, Funny)
Locally Exploitable: No
That right there is the biggest slap in the face! Everyone should have the freedom to fux0r their own machine!
Opensource my ass...
Re: (Score:2)
Well done, the OpenBSD team. (Score:5, Insightful)
Re:Well done, the OpenBSD team. (Score:4, Insightful)
Re: (Score:3, Interesting)
Re:Well done, the OpenBSD team. (Score:5, Insightful)
Then someone pointed out the respective revenues of OpenBSD vs Microsoft, and the whole idea just seemed to evaporate.
Someone decided that people don't care enough about the number of remote exploits found in a given OS. They were probably right.
Re:Well done, the OpenBSD team. (Score:5, Insightful)
My company makes far more than the OpenBSD team brings in, and yet we still respect them and try to emulate their practices. I'm not sure what kind of hubris it takes to dismiss someone's ideas just because you have more money.
Re: (Score:3, Insightful)
It's not hubris, exactly. It's a matter of values. If what you value above all else is money, then the fact that they have less money -- compared to MS, they are effectively penniless -- means that their ideas are not important to you, even if technically good ideas. They won't help you get more money, ergo what you are doing is better than what they are doing.
Your company values things other than money
Re: (Score:3, Insightful)
My company values money an awful lot - it makes staying in business a bit easier. It's just that we take the long term view. Doing these things gives us a better reputation, which is critically important in our niche market. It also means fewer 2AM emergencies and easier maintenance. Basically, we've decided that OpenBSD's values are very profitable, even if they don't choose to dir
Re: (Score:3, Insightful)
Well done. It's not an easy feat to create an OS with so little exploits. The team and Microsoft should take a leaf out of your book.
It is when basically the only thing your OS does "in the default install" is allow SSH logins.
(Which is not to attack the excellent work of the OpenBSD team, but comparing it to Windows is in this fashion is just asinine.)
Re:Well done, the OpenBSD team. (Score:5, Funny)
Ok, make that "more intentional remote access"...
Re:Well done, the OpenBSD team. (Score:5, Insightful)
Re: (Score:3, Insightful)
The default install of OpenBSD includes (from memory, so this is not exhaustive) SSHd, bind, apache and sendmail, all of which are included in the term 'Only two remote holes in the default install' [...]
They're "included" in that the binaries are there, but they are not enabled (except SSH). Ie: they're not part of "the default install" as far as remote vulnerabilities goes.
Re: (Score:2)
Re: (Score:3, Informative)
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.
Re:Well done, the OpenBSD team. (Score:5, Informative)
- 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.Re: (Score:2)
Re: (Score:3, Funny)
What team, the A Team? Should take out Microsoft?
I love it when a plan comes together.
Re: (Score:3, Funny)
Uhh, they did. TCP/IP stack.
Of course, you can't ever say a leaf made the tree...
Re:Well done, the OpenBSD team. (Score:5, Funny)
Not really, since this has nothing to do with Linux. It's OpenBSD, not Linux.
Re: (Score:2)
I've seen people more than once that believe that OpenBSD is a Linux distribution.
Re: (Score:2, Informative)
Re: (Score:2)
Re: (Score:2, Interesting)
Other than kernel 2.0.x (10+ years ago), has Linux ever had a kernel bug that was exploitable remotely?
Re: (Score:3, Informative)
A quick search turns up this from just last May:
http://www.frsirt.com/english/advisories/2006/191
Re:Well done, the OpenBSD team. (Score:5, Insightful)
Re: (Score:2, Insightful)
Personally though, in professional code, bugs are failures. That we tolerate them as a society is nice and all, but in all honesty they're not really acceptable. Which is generally why it's a smart idea to give your customers test code to toy with before the delivery date. That way hopefully they can spot some bugs to report (it also gives them a chance to ramp up earlier on the software so i
It's a feature (Score:4, Funny)
I think they just found the Windows2003 Server Emulator.
Re:It's a feature (Score:5, Informative)
Re: (Score:3, Insightful)
Some amusing interchanges b/t OpenBSD and CoreLabs (Score:2, Interesting)
* 2007-02-20: Acknowledgement of first notification received from the OpenBSD team.
* 2007-02-21: Core sends draft advisory and proof of concept code that demonstrates remote kernel panic.
* 2007-02-26: OpenBSD team develops a fix and commits it to the HEAD branch of source tree.
* 2007-02-26: OpenBSD team communicates that the issue is specific to OpenBSD. OpenBSD no longer uses the term "vulnerability" when referring to bugs that lead to
Advisory Timeline (Score:4, Interesting)
I'm a bit surprised that the summary didn't mention the rather interesting timeline in the Core advisory [seclists.org], which implies an attempted cover up. I don't know all the facts, so I'll let the document speak for itself:
-Fyodor
Insecure.Org [insecure.org]
Re:Advisory Timeline (Score:5, Interesting)
Cover up? The OpenBSD team believed it was only a remote DoS vulnerability until proof of concept code was provided, and re-labeled it as such immediately.
What part seems suspicious to you?
Re: (Score:2)
Re: (Score:3, Informative)
Because, they've never come up with anything security wise:
http://en.wikipedia.org/wiki/OpenBSD_security_fea
Not at all.
Re:Advisory Timeline (Score:4, Informative)
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.
Re: (Score:3, Informative)
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 [openbsd.org] ; many kernel panic bugs going back several years are classified as "reliability" patches ). Once the proof-of-exploit was provided, they re-
Re: (Score:2)
Re: (Score:2)
You really look like an idiot debating this.
And I really look like an idiot trying to school an AC on Slashdot.
Re:Advisory Timeline (Score:4, Insightful)
Sure there is. Think, for example, of a data warehouse containing social security numbers. Would you prefer that that system go down entirely, or that the contents of the database is exposed. A system that detects trouble and shuts itself down until someone fixes it sounds good to me.
Also, by your standards, a power failure is a security hole. That's just not true.
Re: (Score:2)
Re: (Score:2)
They've earned a mulligan, I think (Score:4, Insightful)
As for a "cover up"... well, if such a thing happend I'd say they must really suck at coverups, since we all know about it.
Re:Advisory Timeline (Score:5, Informative)
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 [insecure.org]
Re:Advisory Timeline (Score:4, Insightful)
I really like OpenBSD, but I really miss having an analogue of FreeBSD's portaudit utility. Since the source data used by portaudit provides OpenBSD and FreeBSD vulnerability info, I wonder if anyone has tried porting it...
Re: (Score:2)
They do. I have no doubt the change was made to the appropriate CVS branches (OPENBSD_3_9/OPENBSD_4_0), as hundreds of other improvements are, all the time (long after release). It would be vastly impractical for them to release a patch and errata for every such change made, on the off chance it might be exploitable.
Not really a coverup... (Score:2)
Also, is IPv6 in the default install nowadays? If not, their slogan won't have to change.
Re: (Score:3, Informative)
"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.
Re: (Score:3, Insightful)
But, cover up? Yah right. Please, note that the OBSD team NEVER denied that a problem existed. They fixed it. It was only the wording that was in contest until remote execution was shown and they verified it.
Re: (Score:3, Informative)
From the bugtraq advisory:
From the OpenBSD CVS log:
Doesn't matter how good a C programmer you are (Score:2, Interesting)
I know, those who don't understand what I'm talking about will lea
Re:Doesn't matter how good a C programmer you are (Score:4, Interesting)
Also, it's less efficient to simply use one heap for everything. Instead, an OS kernel written in a language with automatic memory management usually maintains large blocks of memory for the various tasks to work in, like an area for packet construction, an area for I/O buffers, etc. The automatic allocator and GC are told which area to work in, and then create or delete stuff in that area as needed.
So no, it's not generally reasonable to implement the lower levels of any OS with automatic memory management. You're free to try, though.
Re: (Score:2)
Where that keyword tells the gc to use a separate allocation area for these objects. It's not hard to overcome the special challenges of kernel-level code in a safe language, it just takes a small amount of creativity. It's not like it hasn't been done before with Self, JavaOS, Singularity, etc.
The actual reasons why operating system are not written in safe languages today is a little bit of stupidity and a lot that user apps are written in unsafe languages. Making som
Re: (Score:2)
Despite over a decade of being told how great Java would be for writing a kernel, not a single Java developer has yet done it.
Correct. A small group of developers did. Google for 'JNode.' A somewhat larger group of C# developers did the same thing at Microsoft, and called the result Singluarity.
To my mind, the problem with using a language like Java (or anything based on type theory) is that it gives you fine-grained security, but not coarse. It protects you from buffer overflows, but not from SQL injections (as a trivial example). Category theory looks promising, since it allows you to alter the granularity of your reasoni
Re: (Score:2)
Barely "remote" (Score:5, Informative)
Re: (Score:2)
Re:Barely "remote" (Score:5, Informative)
So nobody from the net can crack your machine, they must already me on your local net. This greatly reduces the scope of this attack.
Re: (Score:2)
Re: (Score:2)
Then those people would be fools. Local means local -- you have to have access to the box in question already.
Granted, as far as remote exploits go, this one is pretty hard to exploit (since it needs IPv6 and access to another box on the same subnet), but it's still a remote exploit. It just means somebody has to exploit that Windows box on the same subnet (which may be a simple matter) and use THAT to attack the OpenBSD box.
If the OpenBSD b
Re: (Score:2)
Take over one box at a colo (e.g. fully remote exploit, local account and a really local exploit, pay for it with fake credit card, whatever) then take over any other server on the "LAN"? Or like the University I went to, they had network plugs outside the computer labs in public areas so you could sit there with your own machine. I don't know the physical layo
Re: (Score:2)
If security was a concern in a shared hosting environment you could make it so that even root can't inject fragmented packets.
I'd say the scope of this vulnerability is very limited, the most disturbing thing is the way the OpenBSD team tried to hush it up.
OpenBSD - now TWICE as insecure (Score:3, Funny)
Holy Cow, an OpenBSD Vuln? (Score:5, Funny)
pablumfication (Score:3, Interesting)
Re: (Score:3, Interesting)
_In lower case, the word pablum is often used to describe anything bland, oversimplified and generally unsatisfying, especially a work of literature or speech. This usage is thought to derive from the cereal. Today, the word pablum and the original Latin word pabulum are often used interchangeably. In Canada, pablum remains as a generic reference to any instan
Re: (Score:3, Informative)
Wikipedia has a good entry on Pablum.
OpenBSD Website (Score:5, Informative)
Only two remote holes in the default install, in more than 10 years!
At least they don't hide it.
More popular than you thought (Score:2)
Fixed in OpenBSD 4.1 (Score:3, Interesting)
Can we now please stop using C? (Score:3)
Can we please stop using C?
http://it.slashdot.org/comments.pl?sid=224594&cid
Re:Can we now please stop using C? (Score:5, Informative)
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.
Re: (Score:2)
Re: (Score:2)
Re: (Score:3, Informative)
http://research.microsoft.com/os/singularity/ [microsoft.com]
Kind of overblown, but potentially serious (Score:3, Informative)
- 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.
Forced release? (Score:5, Insightful)
FTFA:
Kudos to Core Security for finding an exploit in OpenBSD code. Seriously, that's impressive. However, it sounds like they're a little too pleased with themselves. "Forced release"? I guess that's technically true, in the sense that a feather exerts a gravitational force on the Earth.
In a nutshell, they reported a problem and OpenBSD fixed it. Then they demonstrated that it was a more serious problem, and OpenBSD backported the fix to the current releases and announced it on their website. After reading the whole timeline, I'm not sure what else they were supposed to have done so that Core wouldn't be "forced" to announce the vulnerability that OpenBSD publicized on their own site as a "security fix" three days earlier.
OpenBSD and the security myth (Score:3, Interesting)
If you cross reference DoS attacks against OpenBSDs changelog and figure that even a small amount (say 10%) of them were remotely exploitable (which is being kind), then you have a lot of remote bugs in OpenBSD and even more in FreeBSD. The fact that the vendor doesn't call them bugs just brings images of DJB to mind, but it doesn't impact the fact that your box could get owned.
What this ultimately means is that, OpenBSD is pretty good when it comes to security, but that their party line is mostly marketing hype. I just submitted a paper to a few conferences dealing with a given bug I've found, it also affects OpenBSD (but it's not a default remote root bug for them), but what it does show is how proactively secure they are, because they copy/pasted the same section of code as everyone else and missed a very obvious bug.
Amiga : ZERO exploits !! (Score:2, Funny)
Re:Moo (Score:5, Funny)
Re:Moo (Score:4, Funny)
why, That's Communism!
Re: (Score:2)
Wrong... (Score:5, Interesting)
...it's roughly 5.67137278 × 10^28 IP's per person
Or, as a recent Ars article [arstechnica.com] put it (much better than I ever could):
Re: (Score:2)
Re:Not in the default install (Score:5, Informative)
Re: (Score:2)
Maybe we should see the same thing on the Microsoft website: "Welcome, users. It has been 43 hours since our last remotely exploitable vulnerability in the default installation
Re: (Score:3, Informative)
Re: (Score:2)
Which simply proves you have never user OpenBSD for anything: I have an OpenBSD 4.0 machine on my desk that I use everyday. That machine is a cheap second-hand Dell laptop with a Celeron 1Ghz and 128MB of RAM (it has been upgraded to 384MB recently). It works perfectly, and allows me to listen to music while surfing the web (Firefox), reading email (Sylpheed), programming (shell, Perl, Python & C, with vim) and controlling distant servers thro
Re: (Score:2)
Currently, the biggest limitation of OpenBSD is the lack of DRI support. This means no 3D on a d
Re: (Score:2)
Languages don't kill people (Score:3, Insightful)
Fully-native object oriented languages like Objective-C are no better than C for security. In fact, they bring their own set of baggage with them. Hy