OpenBSD and the latest OpenSSL bugs [LWN.net]

OpenBSD and the latest OpenSSL bugs

Posted Jun 12, 2014 12:50 UTC (Thu) by niner (guest, #26151)
In reply to: OpenBSD and the latest OpenSSL bugs by JdGordy
Parent article: OpenBSD and the latest OpenSSL bugs

Not only that. He claims to have no time to even skim a security related mailing list but expects others to spend time to cater to his wishes and send a personal email. Spreading emails to a list of interested individuals is exactly what mailing lists are for.

to post comments

OpenBSD and the latest OpenSSL bugs

Posted Jun 12, 2014 12:56 UTC (Thu) by mstone_ (subscriber, #66309) [Link] (8 responses)

bingo. if it's too much work for him to follow the list, it's not clear why it's not too much work for other people to be responsible for keeping track of what he wants to know and making sure he knows it.

OpenBSD and the latest OpenSSL bugs

Posted Jun 12, 2014 17:18 UTC (Thu) by Lennie (subscriber, #49641) [Link] (7 responses)

It all depends on the kind of traffic that mailinglist gets.

I think someone in the comments mentioned that it isn't OpenSSL only.

If that is true it would mean you'll get lots of updates on all kinds of software that is used on Linux/BSD, not just OpenSSL.

Does anyone know how OpenBSD is organized ?:
Specifically how is Theo employed ?

I expected he was the only employee or the OpenBSD Foundation or something like that.

OpenBSD and the latest OpenSSL bugs

Posted Jun 13, 2014 14:42 UTC (Fri) by mstone_ (subscriber, #66309) [Link] (5 responses)

The linux vendors also see traffic about software they don't care about. You look at the subject and ignore what you're not interested in. (Unless you're Theo, then you expect someone else to read the traffic and make sure you are told about exactly that set of things which interest you. In most situations, that person is called a "secretary" and gets paid for the service.)

OpenBSD and the latest OpenSSL bugs

Posted Jun 13, 2014 18:07 UTC (Fri) by viro (subscriber, #7872) [Link] (4 responses)

It doesn't work that way. The volume is a secondary problem - compared to e.g. l-k it's _very_ low-traffic. The real bitch is that a fair number of postings there carry (OK, carried, but I don't believe that anything has changed in that respect) utterly ridiculous embargo terms.

It works like that: $TWIT_WITH_GREP goes over some bunch of libraries and finds a lot of dubious places. Of the "sure, it's badly written and needs to be fixed on general principles" variety. One or two might be exploitable in real-world setups. Good for them; such things need to be hunted down and fixed. Unfortunately, said twit decides to get more PR mileage from that. Easy - let's request a CVE for each instance (exploitable or not) *and* arrange for coordinated PR offensive. Which is where vendor-sec really comes into the picture - twit reports it there and demands a month (or two) worth of embargo. By the end of which they get (Number of Distros * Number of CVEs) announcements, all at once, each referring to them.

If you receive such mail via vendor-sec, you *can't* do anything about the bloody thing until the embargo runs out. Even if the proposed fix is crap and there's a better solution. And yes, sometimes embargoes are needed, but not on such terms.

So I certainly can understand somebody refusing to subscribe to vendor-sec. If something relevant comes up there without embargo terms from hell, I'd appreciate having the report forwarded my way, but that's it - I refuse to honour overblown embargoes. The same goes for Linus, AFAIK.

OpenBSD and the latest OpenSSL bugs

Posted Jun 13, 2014 18:17 UTC (Fri) by mstone_ (subscriber, #66309) [Link]

There's nothing wrong with not wanting to participate, as long as you then accept that there's going to be stuff you're not privy to and don't complain that it's other peoples' job to keep you informed in the way you prefer. Right? In this case, the issue was embargoed and so what you're suggesting is that not only should someone figure out what's important, they also need to decide whether the embargo terms are "reasonable enough" to forward (maybe with some kind of back and forth to determine the reasonableness?). That seems like a high bar for one volunteer to demand of another volunteer.

Note also that you're arguing for your reasons, not the reasons Theo actually stated. "I don't know where I should find the time to be on another mailing list"

OpenBSD and the latest OpenSSL bugs

Posted Jun 14, 2014 22:33 UTC (Sat) by spender (guest, #23067) [Link] (2 responses)

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

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

OpenBSD and the latest OpenSSL bugs

Posted Jun 13, 2014 16:27 UTC (Fri) by dag- (guest, #30207) [Link]

Say hello to procmail !

OpenBSD and the latest OpenSSL bugs

Posted Jun 13, 2014 9:18 UTC (Fri) by jezuch (subscriber, #52988) [Link]

> He claims to have no time to even skim a security related mailing list but expects others to spend time to cater to his wishes and send a personal email.

He claims that he expects them to do that because they're paid for it while he is not.

BUT.

He claims that he has no time to be on "another list". But he wants to be notified anyway - hence be on some other another list. I found it a little funny :)