Embargoes handling

OpenBSD isn’t usually included in security embargoes anymore, likely because they have the bad habit of not playing well with them, although they never technically broken one.

About CVE-2014-0224, Theo de Raadt said in June 2014:

We are sorry that the errata for these libssl security issues are not up yet.
The majority of these issues are in our ssl library as well.
Most other operating system vendors have patches available, but that is because they were (obviously) given a heads up to prepare them over the last few days.
OpenBSD / LibreSSL did not receive any heads-up from OpenSSL.
So hold on, we’ll try to have errata out in a few hours.

But in May 2014, he also said:

The errata would have gone out same day Ted commited the fix, except I was in the Atlas mountains… and then it was forgotten until I got back home.
I’m sure you’ve all got your “processes” for handling these things. But then you get paid for handling these things in some way, don’t you?
We don’t get paid. And therefore, I don’t know where I should find the time to be on another mailing list. It is not like I would have sent a mail to anyone. In general our processes are simply commit & publish. So I’ll decline.

LWN has a nice timeline and some details about the interactions between OpenBSD and the OpenSSL security issues fixed in 2014.

For Stack Clash, OpenBSD release a fix the 18th of May 2017, a day after the issue was communicated to the distros list. The embargo was supposed to last until May 30, but was moved to June 19, as requested by Red Hat. Check the timeline from Solar Designer for more details. Since OpenBSD isn’t part of the distros list, they were notified by Qualys separately, under unknown terms, but it would be surprising that Qualys allowed them to disclose the vulnerability before the end of the embargo.

OpenBSD also handled KrackAttack in a surprising way in 2017. Stefan Sperling, an OpenBSD developer, explained in November 2017 what happened on their side:

What happened is that he told me on July 15, and gave a 6 weeks embargo until end of August. We already complained back then that this was way too long and leaving people exposed.

Then he got CERT (and, thus, US gov agencies) involved and had to extend the embargo even further until today. At that point we already had the ball rolling and decided to stick to the original agreement with him, and he gave us an agreeing nod towards that as well.

In this situation, a request for keeping the problem and fix secret is a request to leave our users at risk and exposed to insiders who will potentially use the bug to exploit our users. And we have no idea who the other insiders are. We have to assume that information of this kind leaks and dissipates pretty fast in the security “community”.

We chose to serve the needs of our users who are the vulnerable people in this drama. I stand by that choice.

On the Lazy FPU state leak (CVE-2018-3665), Theo talked about the vulnerability at BSDCan 2018, allowing Colin Percival to write a working exploit in a couple of hours, making the embargo moot. The OpenBSD people, not part of the embargo, claimed that they discovered (and patched) the vulnerability independently.

Colin Percival, Security Officer for FreeBSD between 2005 and 2012, said in 2018:

Maybe I should have said Theo rather than OpenBSD? But seriously, look at the Lazy FPU thing – someone leaked it to Theo, and his immediate response wasn’t “gee, this sounds serious, I should work together with other vendors to make sure that we can all get this fixed”; it was “let’s publicly disclose the vulnerability at the soonest opportunity”.

I’m not saying that he has agreed to embargoes and then broken them. I’m saying that he has made it clear that he isn’t interested in acting as a productive member of the community.

In 2018, Theo de Raadt complained that Intel didn’t give OpenBSD advance notices for L1TF.

This is likely thanks to all of that OpenBSD was not part of the coordinated disclosure of CVE-2018-14665, a trivial privilege escalation in Xorg (mentioned above in the article).

An interesting outsider in the embargo world worth mentioning is grsecurity:

As a matter of principle, we choose not to participate in embargoes (even for issues reported to us) as they distort public perception of security: differences in response time, level of proactive measures, and quality of in-house security talent is obfuscated through the activity and delay happening behind closed doors. Effective security shouldn’t depend on hoping the “bad guys” don’t have early access to vulnerability information, which is what zero-days are all about.