OpenBSD and the latest OpenSSL bugs

Posted Jun 14, 2014 22:33 UTC (Sat) by spender (guest, #23067)
In reply to: OpenBSD and the latest OpenSSL bugs by viro
Parent article: OpenBSD and the latest OpenSSL bugs

You know vendor-sec doesn't exist anymore right? As in, not for over three years. I guess you also know there aren't month-long embargoes on the new list. Here's the new list: http://oss-security.openwall.org/wiki/mailing-lists/distros . The *maximum* embargo is 14-19 days.

I'm not a fan of embargoes either, so I don't subscribe to such lists. That said, we generally can respond quicker than a distro and are rarely ever affected by public exploits (unlike upstream).

So your arguments are a little stale, and I don't much care for your alternative of "just fixing the bug" with your not-so-cute one-liner commit messages, sometimes introducing new bugs in the process (revealed by subsequent one-liner commit messages).

Seems to me like you want a distraction from the massive problems with upstream's own security handling, as if it's the existence of these cherry-picked security "researchers" from years ago that are continuing to prevent you today from taking security seriously.

A researcher who reports to security@kernel.org today will end up seeing their issue fixed without any mention of security with one of Linus' signature commit messages. It's getting a little old and I'm surprised people are still buying your stale excuses.

-Brad

to post comments

OpenBSD and the latest OpenSSL bugs

Posted Jun 15, 2014 6:16 UTC (Sun) by viro (subscriber, #7872) [Link] (1 responses)

I'm glad to hear about v-s demise; it's been long overdue. As for the embargo policy on replacement... How long was the embargo on CVE-2013-1981 and friends? That's a bit more than a year ago.

Brad, care to give your opinion about the quality of those patches and severity of the vulnerabilities covered by those? My reading of the situation (and I'm not on the list(s) where it had been reported, so I hadn't seen the threads that had led to that) is that

a) authors went after low-hanging fruit - AFAICS, all places they'd found could be found by simple grep and quick look through the hits. Nothing wrong with that, of course.

b) severity had been overblown - that crap needed fixing, all right, but embargo had been unwarranted. Compromise of X server could lead to compromise of clients talking to it (as if the ability of that server to feed an arbitrary input to client *and* hide the reaction from user hadn't been enough) and suid-root X client that could be convinced to talk to attacker's X server could lead to escalation. The practical impact of the first part is nil and the second one needs much more exotic setup than the announcement implied.

c) all that pile didn't get anywhere near enough review - it introduced at least one genuine stack corruption, triggered by real-world programs talking to non-compromised server (NULL written at some location in caller's stack frame). Again, I'm not blaming the patch authors. Shit happens - which is why code review is needed.

d) the lack of code review had almost certainly been due to embargo cutting down on the amount of potential reviewers. Worse, classifying that as "important security fix" had rushed the deployment after the embargo had been lifted.

e) the only reason I can conjecture for the whole sorry mess is that the authors wanted to maximize the PR mileage.

Look, I'm not saying that embargoes are never needed. Or that 14--19 days is horribly long. The problem starts when patch authors get to *demand* the embargo and when it gets tangled into the whole "how severe the bugs in question are, the worse is more impressive" mess...

Anyway, I'm really glad to hear that vendor-sec got replaced by something that might end up being saner. Said that, the bits and pieces of stories I've seen don't leave the impression that much has improved in the last few years... ;-/

OpenBSD and the latest OpenSSL bugs

Posted Jun 16, 2014 16:49 UTC (Mon) by spender (guest, #23067) [Link]

I've read your other comments on the huge pile of Xorg vulns (http://lwn.net/Articles/551860/ etc), you seem to like to bring it up often though it doesn't seem you actually have any first-hand experience with what happened behind the scenes.

Specifically, I haven't been able to find any public evidence that the reporter (Ilja) demanded some ridiculously long embargo, nor does it seem that he reported it to the distros list. He seemed to have reported it directly to the Xorg security team and worked directly with Alan Coopersmith. You can see some mention of details in one of the presentations he gave on the subject:
http://events.ccc.de/congress/2013/Fahrplan/system/attach...
Note slides 5, 29, and 33. On slide 33 it mentions a two week embargo (which would suggest the Xorg team then sent it to the distros list), presumably after all the fixes were created, which took nearly three months.

You seem to be the only one taking huge offense at the handling of all the bugs -- I certainly don't see it coming from the Xorg security team. From the presentation and Alan Coopersmith's tweets: https://twitter.com/alanc/status/417884288466444288 onward, there seems to be mutual respect and appreciation of efforts.

Given that at least 200 bugs were reported and fixed, it makes sense for this to be bundled up into a single update instead of numerous updates. Alan Coopersmith explained the reasoning behind the large number of CVEs already here: http://lwn.net/Articles/552035/ and here: http://lwn.net/Articles/552033/ They weren't demanded by the reporter as part of some PR conspiracy as you previously claimed.

Making a big deal out of two of those 200 fixes puts you ironically in a similar position as these security people you despise ;)

Still, I don't see how cherry-picking specific researchers/reports has anything to do with the new distros list, which wasn't even involved in the creation of fixes in the case you mentioned. Not to mention how this "security circus" that constantly gets referred to prevents kernel upstream from taking security seriously. Frankly, in this instance, given that many of these vulnerabilities were ~20 years old and trivial to spot according to you, we should just be glad someone (not you) finally bothered to look and got them fixed. "Many eyes" and all that.

-Brad