Remote Exploit Discovered for OpenBSD 338
Posted
by
samzenpus
from the patch-it-up dept.
from the patch-it-up dept.
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."
Well done, the OpenBSD team. (Score:5, Insightful)
Re:Well done, the OpenBSD team. (Score:4, Insightful)
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:Advisory Timeline (Score:0, Insightful)
Why is your sig not a sig?
Re:Advisory Timeline (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.
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.
who the hell.. (Score:1, Insightful)
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!]).
Re:Well done, the OpenBSD team. (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: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:Well done, the OpenBSD team. (Score:5, Insightful)
Re:Well done, the OpenBSD team. (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:Well done, the OpenBSD team. (Score:5, Insightful)
Re:It's a feature (Score:3, Insightful)
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:Sure it is (Score:1, Insightful)
Re:Well done, the OpenBSD team. (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 it's win-win).
In the case of OSS, I can see the guidelines being a bit more lax in certain projects (not OSes though) as resources are limited. If some handy perl script has a typo in the command line parser and I need to specify "--demon" instead of "--daemon" it's a bug, but not the end of the world, etc...
That the OpenBSD team treats the bug reports with such speed is a sign of professionalism. Kudos to them even if I still run Linux (hehehe).
Re:Advisory Timeline (Score:1, Insightful)
Tell that to anyone who has an alarm system without a battery backup...
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.
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:WHOA WTF (Score:1, Insightful)
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. 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.
Re:Well done, the OpenBSD team. (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, so you copy good practices even if they aren't going to earn you more money.
Though I think it is fairly simple to concoct a scenario where in the long term it does cost money not to adopt good practices -- such as losing marketshare because of security problems. Short sightedness is also a problem people who value only money often have, at least the ones running publicly traded corporations.
Re:There (probably) was one in November 2004 (Score:1, Insightful)
Well, the Linux kernel doesn't have a default install... But most distros did enable smbfs by default.
Re:Well done, the OpenBSD team. (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 directly financially profit from them.
Re:Advisory Timeline (Score:1, Insightful)
If the developers look at something and think it's a potential security risk, they mark it as such and it comes as a security patch. Look through their history, they've done it several times when they haven't even looked to make an exploit, they just think it's possible, so it's marked as security.
On the other hand, if they do not see the risk, they mark it as reliability unless someone, it doesn't matter who, shows them otherwise.
When has it ever been declared OpenBSD's responsibility to treat anything and everything as the end of the world?
They never used to treat everything as a hole in the system, they treated things as what they assessed them to be, just like everyone else does.
Given a pass? This is a bug that can only be exploited under rare cases and it had been very doubtful that it could be exploited at all until Core showed it to them. Cannot slack? These people are doing a significantly better job keeping their system safe than any other system, if anything, these people are getting pressured far more than they should be. They are human last I checked, except for Bob Beck who is actually 1/4 Moose on his dad's side.
Their entire reason for being is making a system they want to use, that will never evaporate. And you can go fuck yourself for all they care, they don't even want you using their work, they're letting you have it because they see no need to make you write your own code. You're just being an ingrateful little child, complaining about nothing, because you want everything.
Re:Advisory Timeline (Score:1, Insightful)
That's absurd. No facts and it's immediately considered an exploit on vetted code?
I'm not sure where you learned this ideology. I've used OBSD for 8 years and they never do this unless it's blatently clear.
And you know what? Mayve they did consider it and didn't see the issue; it took CORE itself 1 week minimum to deliver PoC, showing this was not a readily seen | trivial exploit, not to mention a couple days, not the usual hours, for OBSD to come up with a fix. iow, the fact it wasn't seen in the first place lends some evidence that this wasn't a readily seen problem.
"They are supposed to investigate EVERY bug as being a potential exploit."
No, they fix known bugs first, which stamps out most issues. Which they did here. Then they learned it was more and fixed the issue within 2 days, maybe less depending on what hours the mentioned communications were actually made.
YOU do understand that CORE seems to have given them partial info? PoC was not given for over a week. You also don't know, seeing the info is only one side of the tale, whether someone was still looking into things on OBSD's end and CORE simply came up with the PoC first.
"At least they used to."
You clearly don't use OBSD and haven't for years, so quit pretending you know how they work and being some basis of how they used to work, because your impression is false; they've never had the attitude you give them. They fix bugs first and write secure code from the get-go with a pretty small team and resources. They don't go doomsday on every bug revealed or write exploits as a matter of course.
"Now they are like
Where did they deny? They questioned, had their own arguments, didn't see the proble, saw their misyake, and immediately fixed and bacported it...
" till they get egg shoved in their face."
"Only two remote holes in the default install, in more than 10 years!"
"And in fact it may be this type of internal behavior that has led to the existance of this bug in the first place. Rather than giving them a pass, they should be crucified for this. They need to be reminded that they cannot go slack or their entire reason for being will evaporate."
Seems pretty clear to me you're on OpenBSD hater and non-user.
Crucified for 2 errors in a decade, one being in IPv6 code whe most of the world is IPv4?
Their entire reason will evaporate, when most of the developers want to write good, secure code, come up with secure solutions, with security in an OS as part of the emphasis, the other being open source for all to use and open documentation?
Frankly, you're a damn, misinformed, assuming nut.