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."
See! I told you ipv6 was evil!
An IP for everyone. Bah!
Have you read my journal today?
freakin rare event, hell must have frozen over! /me takes a snapshot of the moment and feels badly for all the BSD-folk
C|N>K
Remotely Exploitable: Yes
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...
for sale
I'm a self-modifying sig virus
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.
I think they just found the Windows2003 Server Emulator.
* 2007-02-20: First notification sent by Core.
/I kid I kid
* 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 a remote denial of service attack, as opposed to bugs that lead to remote control of vulnerable systems to avoid oversimplifying ("pablumfication") the use of the term.
* 2007-02-26: Core email sent to OpenBSD team explaining that Core considers a remote denial of service a security issue and therefore does use the term "vulnerability" to refer to it and that although remote code execution could not be proved in this specific case, the possibility should not be discarded. Core requests details about the bug and if possible an analysis of why the OpenBSD team may or may not consider the bug exploitable for remote code execution.
* 2007-02-28: OpenBSD team indicates that the bug results in corruption of mbuf chains and that only IPv6 code uses that mbuf code, there is no user data in the mbuf header fields that become corrupted and it would be surprising to be able to run arbitrary code using a bug so deep in the mbuf code. The bug simply leads to corruption of the mbuf chain.
* 2007-03-05: Core develops proof of concept code that demonstrates remote code execution in the kernel context by exploiting the mbuf overflow.
* 2007-03-05: OpenBSD team notified of PoC availability.
* 2007-03-07: OpenBSD team commits fix to OpenBSD 4.0 and 3.9 source tree branches and releases a "reliability fix" notice on the project's website.
* 2007-03-08: Core sends final draft advisory to OpenBSD requesting comments and official vendor fix/patch information.
* * 2007-03-09: OpenBSD team changes notice on the project's website to "security fix" and indicates that Core's advisory should reflect the requirement of IPv6 connectivity for a successful attack from outside of the local network.
* 2007-03-12: Advisory updates with fix and workaround information and with IPv6 connectivity comments from OpenBSD team. The "vendors contacted" section of the advisory is adjusted to reflect more accurately the nature of the communications with the OpenBSD team regarding this issue.
* 2007-03-12: Workaround recommendations revisited. It is not yet conclusive that the "scrub in inet6" directive will prevent exploitation. It effectively stops the bug from triggering according to Core's tests but OpenBSD's source code inspection does not provide a clear understanding of why that happens. It could just be that the attack traffic is malformed in some other way that is not meaningful for exploiting the vulnerability (an error in the exploit code rather than an effective workaround?). The "scrub" workaround recommendation is removed from the advisory as precaution.
* 2007-03-13: Core releases this advisory.
Got owned, OpenBSD?
haha
luckily i'am running Windows so no remote exploits for me, take that OpenBSD !!!1@#x"3eleventy !
I'm a bit surprised that the summary didn't mention the rather interesting timeline in the Core advisory, 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
It was as if several dozen antiquated nameservers suddenly cried out in pain"
2 aint bad. Whats Microsoft at for the decade, 2000?
Libertarian Leaning Political Discussion Forum.
Perhaps it would be better to update the kernel
There will be buffer overflows. The solution is to not use C for handling data from over the network. Use a language that has memory safety. I think JNode is on the right track. They have a small amount of code (assembly in this case) for running the virtual machine, and everything else is done in Java. Java has no memory access. Buffer overflows of a certain kind can exist but the standard buffer overflow exploit is nearly impossible.
I know, those who don't understand what I'm talking about will leap in and say, "Java has to run in a JVM and what language is the JVM written in? Ha! It's in C (or assembler) so it can still have buffer overflows!" This is so naive. First, the JVM runs Java code, which has no memory access. It does not run untrusted code handed to it over the net. Second, and most important, it is a very small piece of code with a rigorous definition of what it should do. It's possible to verify a small, rarely-changing bit of C code with a rigorous specification. It's not really possible to verify correctness of a huge constantly-changing C codebase, like the OpenBSD kernel and system utilities.
Anyway, trying to have a huge secure codebase in C is an exercise in futility, as OpenBSD has shown. Relative to other operating systems, OpenBSD is small and feature-poor. And their dev team must be among the best in the world for eliminating these types of bugs. And yet they still get bitten by them.
"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.
Wow, OpenBSD's security rating just went from "999,999" on a scale of 1 to a million to "999,998" on a scale of 1 to a million.
They just asked for proof of concept code before they'd declare a remote control vulnerability. That's not really much of a coverup. If you were OpenBSD, wouldn't you want to be really, really sure you'd found a remote root vulnerability?
Also, is IPv6 in the default install nowadays? If not, their slogan won't have to change.
Laws do not persuade just because they threaten. --Seneca
Thank GOD I run the company webserver on NT!
For this to manifest itself, you will have to manually enable IPv6, which is NOT on in the default install. Thus OpenBSD can keep its "x years without a remote hole in the default install" claim.
Amiga : ZERO exploits !! About as many users !!
I'll spot them some skepticism or overconfidence. It's been proven again and again that they're right to think OpenBSD is a hard target, so it's understandable that they wanted to see proof before bumping their counter up.
:-)
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.
With reasonable men I will reason; with humane men I will plead; but to tyrants I will give no quarter. -- William Lloyd
Just OpenBSD. There are lot of other *bsd's.
..uses IPv6? That's the first thing I turn off on every OS I've ever set up for a client (at least, ones where I can recompile the kernel).
This is about as interesting as finding a hole in Gopher. (Except, well, Gopher is something from the past, and IPv6 is perpetually in the future [any day now, we'll all switch!]).
My hat is off to Core Systems. This takes a lot of dedication as needles in the BSD haystack are very small indeed. I'm curious as to whether this was found by protocol fuzzing.
I dunno - seems if you need a local connection to the computer, even if through a few ethernet cables and a hub, it's not a remote exploit. I mean, if there was an exploit that could only be taken advantage of by a USB packet after passing through several hubs, it would still be considered a local exploit.
gloating. Perhaps they know of an OS with a better record?
Can anyone explain what pablumfication means? The only hit is the very same report. I thought maybe it was pablumification, but that only gets two more hits.
-The Sox won the world series
-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
From the OPENBSD Website:
Only two remote holes in the default install, in more than 10 years!
At least they don't hide it.
In fact Microsoft has an OS that has zero remote exploits in a default install: DOS. No remote access (net support wasn't a part of a default install), therefore no remote exploits. OpenBSD likes to wave their cocks around about it a whole lot but what it comes down to is the OS isn't really comparable to most default Linux or Windows installs. It does the "everything is off by default" tactic. Ok, fair enough, but that doesn't really mean anything. After all one could say virtually any OS that has a firewall that blocks all inbound traffic has no remote exploits by default since there is no remote access by default.
The real question isn't how many exploits there are in a default install, it is how many there are in a well maintained install in a particular environment. When you have a bunch of services opened up and running how well does something do?
I'm not knocking OpenBSD on the security front, I am just saying that their security claim isn't a real meaningful one in terms of overall secure design. It is just proof of the statement "If there is no service, there can be no denial."
This bug just crashes the machine. Anyone who uses a desktop or notebook knows that crashes happen from time to time, regardless of the OS. There is no known way to run attacker's code, and TFA suggests that there is unlikely to be one.
OpenBSD is only a target because it is so ubiquitous. If Microsoft windows ever becomes as popular, it too will become the target of such attacks. ;)
If only OpenBSD were suitable for anything beyond a firewall.
Muslim community leaders warn of backlash from tomorrow morning's terrorist attack.
Fortunately, that bug has been fixed before the OpenBSD 4.1 CDs were sent to the press.
{{.sig}}
...it's roughly 5.67137278 × 10^28 IP's per person
Or, as a recent Ars article put it (much better than I ever could):
I am NaN
Isn't it enough? even the best programmers can make a mistake with C (and no, it may be programmers that make the mistakes, but you have to be at least a Q in order to make an 100% correct C program).
= 18191856
Can we please stop using C?
http://it.slashdot.org/comments.pl?sid=224594&cid
"Default install" means "enabled by default". Look at the errata. For example:
# 001: SECURITY FIX: March 25, 2006 All architectures
A race condition has been reported to exist in the handling by sendmail of asynchronous signals. A remote attacker may be able to execute arbitrary code with the privileges of the user running sendmail, typically root. This is the second revision of this patch.
Since sendmail only listens on localhost doesn't affect slogan.
Not mention apache or bind, that must manually enabled.
Yeah, this makes the slogan a nonsense (and I use OpenBSD everyday and I really like it, every Internet faced system runs on it).
"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/
Some might argue that C# and Java code is compilable to native code ("just look at gcj"), but the fact is that those compilers include a huge lump of library code into the final binary which is both written in another language (often C) and that depends heavily on OS functionality.
Of course, in the end, even C isn't enough. When writing kernel code, one will always need assembler in a couple of places to do the really low-level things like setting process control registers in order to do context switching and set virtual memory parameters.
Once the VM code has been written in a low-level language like C or assembly, though, the vast majority of kernel code can be written in a language like Java -- Just look at JNode, which has a small VM written purely in assembler, with all the high level kernel code like scheduling, drivers or the network stack implemented in Java. I do have criticisms against such systems, but it does prove that it is possible to write a large part of the operating system in Java.
what, do they change their logo each time an exploit is found
Somebody please paste it already
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.
Dewey, what part of this looks like authorities should be involved?
http://en.wikipedia.org/wiki/Java_Servlet and http://en.wikipedia.org/wiki/User-mode_Linux and http://www.gnusolaris.org/gswiki just to name a few- as far as "pure" java goes (it's a pain in the ass to read) their are other's that aren't: http://processing.org/ for one
I'm not pretending I'm more knowledgeable about security than the OpenBSD devs, but I have to say this: if they had programmed the thing in a safe language (specifically, one which does not allow buffer overflows to be coded), this vulnerability would not have occurred.
The fact that the OpenBSD team didn't catch this vulnerability, despite their expertise and effort, means it could happen to anyone. It would be well to remember this next time someone says "yeah, C is an unsafe language, but you just have to be careful to check your bounds and use fgets instead of gets". Sure, no useful language can completely prevent one from writing insecure code (so there is always responsibility on the part of the programmer), but every vulnerability that the language rules out is a win.
C is one of the worst languages security-wise (and, arguably, productivity-wise). I would hesitate to call anything written in C "secure".
Please correct me if I got my facts wrong.
I never really looked at OpenBSD under the hood, so I'm kind of surprised that there are function pointers being stored inside of complex dynamic structures like that. If I were on the team, I'd be taking a long hard look at every damn function pointer that gets stored anywhere, to make sure none of those can get overwritten either. Sheesh, I normally think of the code segment and the stack as the only places where this kind of crap can happen, but obviously that's just not the case. Yeah, in hindsight, I'm a moron.
Another thing that springs to mind here, is that I wonder if the basic idea behind this attack could be applied even to "safe" languages; anywhere where there's some sort of callback that gets stored with data. Even in a Python program, if you store a callback of some kind inside of some data, and someone figures out how to corrupt that data, the callback could end up not going where the programmer expected it to. Hm. Of course, the trick is: how would an attacker corrupt the data? That's where "safe" languages still do feel safer.
Anyway, all that aside, this story doesn't really change my overall admiration for the OpenBSD team. It's a shame to see them not be able to keep their undefeated bragging rights, though.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
I made a mistake in a Ruby program where I swapped two sets of numbers and stuffed the wrong ones into a database table, which caused all kinds of major hassles...why didn't Ruby stop me from being so stupid? Why didn't Ruby know that I was putting cost into price and price into cost? What a stupid language...Can we please stop using Ruby?
To your point, every programmer makes mistakes in every language. C has the distinction of being the language that most operating systems and even other languages (e.g. Ruby) are written in, so when a bug comes up in said operating system or language, people always shake their fist at C and say how direct access to memory is evil and must be avoided like the plague.
Problem is, *somebody's* gotta do it. Those variables in don't come for free, even though it seems like it. Behind the covers Matz or Guido or whomever had to malloc() and cast and deal with all that nitty gritty to give the illusion that it's all for free. When a problem comes up, as it inevitably will, they fix it and move on.
It all comes down to problem domain. If I need to parse a text file and put some data into a database table, I'll whip up a Ruby script and away I go. If I need to write an operating system or a new language, I'll pick the tool that gives me the most flexibility and power, always acknowledging that I'm juggling chainsaws, and that for me, as for pretty much everyone else in the same boat, is C.
First, there has to be a lot of low-level code just to be able to boot most modern computers. Any high-level, non-native language (Python, Perl, C#, etc) need to have an OS to run their VM. Anything low-level, such as disk access, memory management, process management, etc, requires more-or-less direct access to the hardware. This means assembly, in many cases.
.Net framework, and most other popular languages. And it's easier to take advantage of a Perl or Python or .Net exploit when you find them, as you don't need intimate knowledge of the underlying architecture.
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. Hybrid ("half-assed") object languages like C++ are worst of all, as they unite the simplicity of Brainfuck with the inherent security of C and the speed of Perl. (Drawbacks of C++ exaggerated for comic effect. If you are a C++ weenie, please don't take offense.)
When it comes down to it, for general-purpose operating systems, there's not been found a better way than the combination of ASM + C.
I think the issue is, where does the OS stop and the application space begin?
Does the whole TCP/IP stack *need* to be written in C? Probably not. Considering the amount of use it gets, it's probably a great place to optimize for performance, though, so writing it in C helps.
And I'm not convinced the problem is the language. The OpenBSD folks have written a good, solid OS in C, with very few exploits. I've seen exploits in Perl, Python, C#, the
As usual, the debate is not as simple as, "C bad, everything else good."
Anyway, that's my rant, and I'm sticking to it.
Microsoft is to software what Budweiser is to beer.
haha
See http://www.ubuntu.com/usn/usn-30-1; something like 7 vulnerabilities were found in the kernel's smbfs driver which could be used for remote DoS and potentially for remote root, at least on some configurations (the Linux community decided to fix the bugs instead of waiting for exploit code to appear). There may have been other remote root exploits since then -- I haven't been keeping track.
Truely remotely exploitable bugs are rare on any OS. As far as I can tell, Windows has had 3 in the last 5 years (MS03-001, MS03-049 and MS06-040). There was a remote DoS in 2005 (MS05-051), but everything else has been on the scale of "get the user to click open this malformed file/link/whatever". Bad, but an order of magnitude better than something where an attacker can just own you with no action on your part.
3 in 5 years is definitely worse than OpenBSD's 2 in 10 years record, but many linux fans seem to have the impression there's a remotely exploitable bug found in windows every month....
And yeah, to stave off the responses, its tricky on what you call a "remotely exploitable" bug...
Take the trio of MS-039, MS-040, MS-042 (which my search missed while writing the above post). Yeah, they are remotely exploitable, but for most configurations, you need to have valid logon credentials to the machine... Again, its bad, but even if you had an upatched box unprotected on the net, those wouldn't enable remote code execution unless the attacker could already log onto the machine.
I think its interesting that BSD doesn't consider DoS attacks as being a vulnerability anymore, this is especially interesting when you consider that many DoS attacks that are reported end up being remote code execution vulnerabilities that the given researcher couldn't figure out, or the vendor didn't take the time to figure out. This is especially the case with OpenBSD if you look at the CORE timeline, the OpenBSD team attempted to say remote code execution was impossible, as they did when Dowd found the OpenSSH bug, and it took a proof of concept to make them accept they had another bug.
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.
The question is when will Symantec and/or McAfee jump all over this.
Is it not time for their respective security "experts" to publish articles on
BSD/Linux/Unix being overridden with holes/bugs/malware etc based on this
new "evidence" on how BSD is no different than Windows?
That seems to be their tactic on OS X.
The Firefox team somehow has a better policy about this type of bug than the OpenBSD team. Denial-of-service bugs that show signs of memory corruption are considered the same as actual remote code execution exploits, even if no method of executing code is known. (Of course, "remote code execution" in Firefox means visiting a malicious website.) Such exploits appear in red on this page along with the direct exploits: http://www.mozilla.org/projects/security/known-vul nerabilities.html
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
My local Starbucks offers IPv4 wireless. As well as everyother hot spot around here so I highly doubt thats going to happen ;-)
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.
If that's true, they nail the Windoze machine on the other side and blast you from your own DMZ. Once again, your network is only as strong as it's weakest link. This is why I have no Windoze in my network.
Friends don't help friends install M$ junk.
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.
That's only true if your local network is not filled with an OS that has a 1/4 botnet ownership rate. When your own machines can be used against you, all bets are off.
Friends don't help friends install M$ junk.
Great! I knew what pablumfication meant but now I can't guess what pedesagittry is. Please explain.
Send email from the afterlife! Write your e-will at Dead Man's Switch.
Can't understand why you here at /. spit at Windows everytime a mere new bug is found in it, when OpenBSD just doubled its known bugs list !
Press release from the borg marketing machine: The number of bugs in the OpenBSD system is doubling every year!
From TFA:
Would you mind explaining to the rest of us where Microsoft Windows is a specific requirement for any of the stated conditions?
Or perhaps you could explain how any operating system could stop a user with malicious intent from sending or relaying bad packets?
This sig intentionally left blank.
But if you want to be fair then OpenBSD should take notes from Microsoft on how to be *successful*.
The problem with both points is they assume that these two entities are striving to be like each other when they are not. At all.
I think from now on it should be called OpenBSE.
Would you mind explaining to the rest of us where Microsoft Windows is a specific requirement for any of the stated conditions?
Sure, I can do that. It's not really a requirement, it just makes it easy to do and expands the scope out again. Of course, there's not much of a reason to nail the OpenBSD machine if you already own the clients that enter the data in the first place. I suppose the point of all of this is to worry about and eliminate the biggest problems first. Things like OpenBSD are broken once a decade, while Windoze is never fixed.
It's nice to see you back Kieth.
Friends don't help friends install M$ junk.
If you mean, did the CADR processor read/write memory at addresses, then yes it used "manual memory management".
If you mean, did the system software use garbage collection for managing resources, then no it did not use manual memory management, it used GC.
As in "the object oriented programming style used in the Smalltalk and Actor families of languages is available in Lisp Machine Lisp, and used by the Lisp Machine system software".
Sheesh, get it right.
You just replied to me with a link to the post I was replying to in the first place. Brilliant! I guess you can't really explain what Windows has to do with any of this, so your only recourse is the Twitter Tautology:
If this is the only way you can force Windows into the debate, you've already lost.
This sig intentionally left blank.
You just replied to me with a link to the post I was replying to in the first place. Brilliant!
Sorry, but no loss you read all of my posts anyway. Keep reading.
Friends don't help friends install M$ junk.
"I'm stupid and I can't do anything about it. Sorry."
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
by anyone who doesn't know the hole. It's a race.
Sure, the average user who sees the claim doesn't really fully appreciate the meaning, but _every_ OS is in the same race. So sometimes it's okay to let some of the semantics slide.
Perhaps it would be more forthright to say "Only two known remote holes found before we patched them." or something like that, but that would also lead to a miscommunication.
The point is that it is that much better than anything else available in this way. That part is not a miscommunication.
joudanzuki
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.
- AmigaOS 4.0 final is out!
Does Java as open-source and under GPL count?
No, this can be guaranteed only to the extent that the underlying language implementation is safe. There's plenty of space for errors in implementing a language, which can in principle lead to exploitability. (Do you want to vouch for the absolute security of, say, the Java HotSpot VM? I've seen it dump core, I can tell you.)
Are you adequate?