DISQUS

Jon · 2 years ago

Here's a "read in-between the lines" paragraph from the advisory:


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 word "default" is used three times in a very long sentence... Indeed.

Chris Rohlf · 2 years ago

I have not tested it, but interestingly enough it can be triggered when on the vulnerable boxes local lan, even if it doesnt have an IPV6 address configured?

From the advisory...

"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."


The fact a function pointer sits in the attacker controlled space screams "yes remote code execution is possible!" to me, and the ret2text example to trigger ddb is a great POC.

dimitry · 2 years ago

At first it sounded like OpenBSD team did not want to be wrong... but now their banner lists "Only two remote holes in the default install, in more than 10 years!"

Dr. Strangelove · 2 years ago

OpenBSD was created out of Theo's desire to "not be wrong", and the rest of the NetBSD team not being able to stand it before. OpenBSD probably has the absolute most sinister vulnerability disclosure model in the history of OS products. I'm a bit fuzzy on the numbers but IIRC, there have been at least (if not more than) 2 dozen exploitable bugs in OpenBSD that were silently fixed via CVS in the last 10 years. No notification, no ERRATA, no Changelog, OpenBSD team member discovers bug, patches, _never tells anyone_.

They are so concerned with their outwardly viewed security posture and aesthetic image, that they feel the need to hoodwink their customers about the nature and extent of security problems in their product.

Has Theo ever not been a double-talking self-righteous security debutante?

yuhong · 3 months ago

"I'm a bit fuzzy on the numbers but IIRC, there have been at least (if not more than) 2 dozen exploitable bugs in OpenBSD that were silently fixed via CVS in the last 10 years. No notification, no ERRATA, no Changelog, OpenBSD team member discovers bug, patches, _never tells anyone_."
Well, to be honest, Linux also does this sometimes:
http://lwn.net/Articles/297366/

dfc · 2 years ago

what is “pablumfication”

Thomas Ptacek · 2 years ago

"Making a pejoritive term apply to the OpenBSD project".

Jordan Wiens · 2 years ago

Not only that, but it looks like they screwed Core over on the release of the announcement too, not coordinating so the vulnerability announcement could go out with patches. I blogged it a bit here:

http://networkcomputing.com/blog/dailyblog/arch...

Matt · 2 years ago

OpenBSD has avoided the term "vulnerability" for some time. Distinguishing between a denial of service and a remote exploit is important. "Vulnerability" is too vague.

That being said, I personally consider a ping of death a "vulnerability".

ivan · 2 years ago

Random interpretation of security advisories seems to be a popular sport and also it seems opinions are like security bugs: everyone has one and sometimes... more than one :)

In any case, Theo (OpenBSD's project leader) was quite clear in his emails about why he thinks a denial of service should not be called a vulnerability: Because in doing so the term vulnerability is rendered irrelevant, if you call both a DoS and a remote exec bug the same users will not be able to differentiate what "really matters" from meaningless vulnerability reports (search for 'pablum' for the specific term Theo used).

We disagreed on that aspect and now, after the IPv6 mbuf bug report is done and gone, we continue to disagree. We consider a remote DoS a security issue not only because it has a direct effect on availability but also because a remote DoS can be aconvenient building block for a composite attack (for those lacking in creativity: think DNS).

But disagreement did not prevent them from fixing the bug. They did fix it very quickly but they were not very forthcoming about what was exactly the problem and why they thought it wasn't exploitable and since they didn't consider it exploitable they did not seem to care about doing anything more than just committing the fix, issuing a patch and noting the "reliability fix" in the project's Errata page.

Core considers every bug exploitable unless throughout investigation produces convincing enough technical results to make us think otherwise. Even in that case we remain doubtful because there's always the possibility of somebody out there that is smarter, more motivated or that has more time to look in to it and that will prove us wrong (look up "humbleness" or "cautiousness" for appropriate terms to describe this viewpoint), so obviously we were not satisfied leaving it at that and Alfredo decided to continue investigating.

For those that are now saying that exploitability was evident and that it should have been obvious: I challenge you to backup that statement based _only_ on the original patch. It wasn't even easy to figure out why and where the kernel crash was actually being triggered, ddt traces showed so_receive as the culprit and not even in a systematic manner.

If you have not been through the vuln. reporting process: What you can read in the advisory describing the timeline and nature of the communications with the vendor is ABNORMNAL. The typical process is usually MUCH WORSE than that. It's just that we decided to make the part of the process more transparent than what most vendors and researchers usually do.
@strangelove: Would you care to point to the diffs or CVS commits that show those 2 dozen silently fixed exploitable bugs in OpenBSD? I'm not doubting you or hmm well..maybe I am, I'll have to think about it, but even if you are right how is that different than what *every other software vendor* has been doing for years?
@jordan: I wouldn't say that they screwed us over because they did not coordinate release dates with us, a "forced release" -the bug reporter disclosing due to an external event- or a "user release" -the bug reporter disclosing due to his unilateral decision- is not necessarily bad or any more "irresponsible" than a fully "coordinated release" planned for, say December 2009, and completely devoid of any meaningful technical details, disclosure of which can be also conveniently promised for some random future time and afterwards systematically ignored as a follow up item :)

And...ohh yes..there is PoC in the advisory. why? it seems like the best way to prove beyond any shadow of doubt the the bug is exploitable for code execution, because it is useful to test if a system is vulnerable and because it makes it _a lot_ easier to develop a network IDS signature (or please tell me how to write an IDS signature using _only_ the original diff as your source of information)

Dave G. · 2 years ago

Ivan:

One difference between OpenBSD and everyone else is no one else has "Only 2 remote holes in a default install, in 10 years" on their main webpage. If they silently fixed a remote... then they aren't telling the truth (big if)

Jordan Wiens · 2 years ago

@Ivan: I suppose "screwed Core" wasn't quite the best way to put it. Mainly, it looks like they were "operating outside of the best practices for responsible disclosure" with you guys. There, is that summary pablum enough for everyone? ;-)

I realize that most disclosures happen at a much slower rate and with less communication than this one (my final note in my blog entry was that the OpenBSD guys fixed it really quite rapidly, all things considered), but I think we can hold them to a higher standard and expect much more than just a little better than average, much like Dave G. points out.

If OpenBSD wants to be the paragon of security best practices (and hey, they're probably closer than anybody else), that includes coordinating with bug reporters better, and most definitely includes (as you point out) erroring on the side of caution and treating a remote kernel DoS as a serious security issue, whether or not you call it a vulnerability, and whether or not you can immediately identify it as remote code execution exploitable.

All-in-all, they needed to step up to the plate and handle this one better.

James Holt · 2 years ago

dfc: "pablumfication" is the act of making something tasteless goo, turning something to mush. It's used when you over blend something. It's also used when you talk about over simplifying things, babifying it, so that it no longer hold it's true meaning but is simple enough that even a child can ingest it. Canadians use the term, a lot in the northern Ontario area.

Thomas Ptacek · 2 years ago

Apparently, every one of those Canadians is involved with OpenBSD:

http://www.google.com/search?client=safari&rls;...

James Holt · 2 years ago

Nah, though apparently some use pablumification.

Thomas Ptacek · 2 years ago

A whole three of them, that I can find:

http://www.google.com/search?client=safari&rls;...

James Holt · 2 years ago

Well, having just gotten off the phone with my father, who lives in Thunder Bay (google it if you dunno), I asked him what a few other terms for babying are. His response: "Well, there's coddling, pabluming, dumbing down, simplifying, shit, I don't know, you doing a word search?"

Just because the Internet doesn't give a detailed readout on a word, doesn't mean it doesn't exist. Hell, I am sure there is some Newfie slang (google if in doubt about what that is) you'll never get to read online.

Thomas Ptacek · 2 years ago

Newfie slang = sea shanties and pirate talk.

James Holt · 2 years ago

Well, no, it's largely Gaelic thrown into English in a haphazard manner and English with random letters removed. I doubt you've ever read someone respond, "aie dunnae ken," instead of, "I dunno."