Would it have been possible to tell Theo "hey, a serious issue is going to be released at <deadline>. I know you have a big release coming up. I strongly advise you to delay the release by a week so you can properly react to the disclosure. I'd tell you now, but I don't trust you not to break the embargo".
I don't know if it would actually work, but that would at least put responsibility for handling this on Theo.
I was dealing with a multi-vendor security vulnerability in 2005. I asked Theo some questions, determined that OpenBSD wasn't affected, and told him "ok, nothing to worry about here".
Theo's response was to (a) announce to the world at large that I was coordinating disclosure of a major vulnerability, and (b) threaten to withhold information about OpenSSH vulnerabilities from FreeBSD unless I shared details about this vulnerability with him -- even though it didn't affect OpenBSD!
So... my best guess is that Theo's response to your proposed email would be "hey everyone, eridius is going to be announcing a vulnerability at <deadline> and he's refusing to tell me what it is".
I kinda get the rationale for breaking embargo and disclosing information about a vulnerability to the world. I don't agree with it, but I at least understand why someone might think that's a reasonable thing to do.
I don't at all understand why anyone would try to publicly announce the fact that a vulnerability exists without actually knowing the details. The fact that the exists some vulnerability in a product doesn't give you enough information to protect yourself from it (short of not using the product at all, but that's generally infeasible). But the knowledge that there is a critical vulnerability in a product does give malicious actors reason to dedicate effort towards probing that product to try and rediscover the vulnerability. So announcing this helps nobody and potentially causes great harm.
What? It's not just malicious actors that work on researching this stuff. Spectre and Meltdown leaked well ahead (5 months ahead, in fact, even though nobody paid attention) of the the embargoed patch. People found exploits and started working on defense before the official patches released. Good research into similar vulnerabilities got a huge head start rather than having to wait.
You should assume that well-funded, capable and malicious (at least from someone's perspective) state-level actors are aware of and exploiting these flaws _whenever_ they exist. It's their mandate to do so.
I'm not sure what your point is. If you're aware that an embargo exists, then you're aware that patches are already being worked on. Telling the world that a vulnerability exists in a particular product, without knowing the details, doesn't cause patches to materialize that wouldn't have otherwise (remember, the patches are already in progress), all it does is enable attackers to concentrate on that product.
And yeah, perhaps nation-state actors already know of the flaw (but perhaps not as well, they're not omniscient), but for most people, it's not nation-state actors that are the biggest threat, it's all the other malicious people out there.
The patches are already in progress for folks that are part of the embargo. Not anyone else. BSDs, Linux distros that aren't RHEL or Debian based, and niche OS almost always get left out in the cold.
> So... my best guess is that Theo's response to your proposed email would be "hey everyone, eridius is going to be announcing a vulnerability at <deadline> and he's refusing to tell me what it is".
The problem comes if someone is specifically involved with a specific project. You've just seriously narrowed the search space for new vulnerabilities for someone by several orders of magnitude. The specific person who is named, or the organization who is releasing the information, may narrow the search space even further.
What about caring for users? If I know X is vulnerable I can decide to disable X by default for all OpenBSD users without needing to know the details.
Knowing the details would make the difference between drastic and inconvenient mitigations (maybe no graphics at all) and just "disabling legacy drivers and lose the setuid bit".
If after my warning hackers start focusing on X, my users are already on the run: it isn't a problem for them.
Sooner or later one of these vendors will start leaking without Theo’s grace and the embargo will protect the exploiters. I say axe the embargo and get into a habit of real time incident management.
Do you have a source? Google got me only KRACK, which doesn't mesh with your comment. They did participate in that embargo, for six weeks, then refused to extend it to three months because the information was widespread at that point, including to US government agencies, so they felt it likely to be exploited. They communicated this beforehand, got the OK, then patched it silently, which while potentially revealing is no announcement. Their actions seem consistent with a goal of minimizing exploitation across the industry, not some quixotic dedication to non-secrecy. Even the least charitable interpretation of their behavior would lead one to notify them weeks beforehand, not hours.
Colin Percival was the FreeBSD Security Officer 2005-2012. In that role, he interacted personally with members of the OpenBSD team (and Theo de Raadt in particular) in discussing vulnerabilities with them; this is not necessarily public communication. Elsewhere in this HN thread, he discussed OpenBSD's/Theo's handling of an unspecified vulnerability in 2005, and the "Lazy FPU" vulnerability in 2018. Perhaps one of the more salient bits is when he wrote "I'm not saying that he [Theo] 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." As a member of the broader security community, and of the BSD security community in particular, Colin is somewhat uniquely qualified to make that statement on his own credibility.
Replying to him in the thread is Ted Unangst, a high-profile OpenBSD developer.
People make inferences all the time. In order to discover security vulnerabilities in the first place, you have to make inferences about how permissions or memory accesses are mishandled.
Vulnerability disclosure is a hotly contested topic in the industry and Colin's comments can also be interpreted as saying Theo has no intention of falling in line with an opinion he clearly disagrees with.
Given that Theo maintains OpenBSD and what has come out of the project (https://www.openbsd.org/innovations.html), I think it's pretty clear that Theo is an extremely productive member of the community.
> [Theo] isn't interested in acting as a productive member of the community.
That's not saying he is not an extremely productive member of the community. It's saying that he is not acting in a way appropriate for that role. It's like when people say that Trump is not presidential, they don't deny that he is president.
I see this comment on every discussion regarding OpenBSD and security vulnerability embargoes. Have they stated they won't stick to embargoes or agreed to one and then broke it in the past?
There's the KRACK vulnerability issue [1] where OpenBSD pushed a minor patch and published information on the originally agreed embargo date, which was extended. OpenBSD made sure to not mention the attack and instead say that it was fixing an OpenBSD-specific issue, and others agreed that it didn't constitute a violation of the embargo agreement.
However, given Theo de Raadt's colorful past, OpenBSD's relatively small userbase, and this relatively minor incident, I can see how other companies may think that it's not worth the risk of including OpenBSD in an embargo. It's not fair, but it is what it is.
tedu is one of the more prolific OpenBSD contributors and has had a front-row seat to the goings-on for a long time. If his experience is that "facts don't matter", literally how can he provide you any kind of contribution that would satisfy you that also doesn't contradict himself?
It's an important opinion, without any unnecessary words added.
"There is a related issue in that OpenBSD broke the embargo by publicly committing a patch to add a 1MB stack guard on May 18 — one day after the private disclosure of the problem. This has raised a number of questions, including whether OpenBSD (which is not a member of the distros list) should be included in embargoed disclosures in the future." https://lwn.net/Articles/726580/
> Why did OpenBSD silently release a patch before the embargo?
OpenBSD announced an errata on 30 August 2017 that silently prevented our key reinstallation attacks. More specifically, patches were released for both OpenBSD 6.0 and OpenBSD 6.1.
> We notified OpenBSD of the vulnerability on 15 July 2017, before CERT/CC was involved in the coordination. Quite quickly, Theo de Raadt replied and critiqued the tentative disclosure deadline: “In the open source world, if a person writes a diff and has to sit on it for a month, that is very discouraging”. Note that I wrote and included a suggested diff for OpenBSD already, and that at the time the tentative disclosure deadline was around the end of August. As a compromise, I allowed them to silently patch the vulnerability. In hindsight this was a bad decision, since others might rediscover the vulnerability by inspecting their silent patch. To avoid this problem in the future, OpenBSD will now receive vulnerability notifications closer to the end of an embargo.
In other words: "We said they could make their users more secure by applying the patch, and they did."
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.
I think you've been cut out of enough embargoes to understand the openbsd position. Embargoes hurt users. The decision to not work together on lazy FPU was made before Theo got involved.
What Theo and others, including myself, have made clear is that embargoes suck, and we will complain about them as is our right, but we will attempt to honor them if that's how it going to be.
I think you've been cut out of enough embargoes to understand the openbsd position. Embargoes hurt users.
I disagree. Embargoes are good for users, as long as (a) people actually respect the embargoes (rather than leaking details, whether to Theo or on a public Linux kernel mailing list), (b) the right people are part of the embargo, and (c) the embargo is not unreasonable long (Intel in particular fails here).
The decision to not work together on lazy FPU was made before Theo got involved.
Leaving aside the question of who refused to sign an NDA, after details were leaked to Theo he made a decision to go public rather than attempting to work productively with other vendors.
What Theo and others, including myself, have made clear is that embargoes suck, and we will complain about them as is our right, but we will attempt to honor them if that's how it going to be.
You can complain all you want, but if you want other people to give you advance notice of vulnerabilities they find, you should be prepared to give people advance notice of vulnerabilities you find. As long as OpenBSD has a policy of "bugs we find get fixed immediately, without talking to other vendors" you're going to run into problems here.
Which is why I love OpenBSD. You're literally complaining that OpenBSD closes security holes too quickly! As a user I want that.
We need to be honest that embargoes serve a couple different purposes. One might be to prevent the leaking of information to malicious actors, and another is to protect vendors and HW manufacturers from embarrassment. As a user I don't care about the latter. Also, as someone concerned with the state of the world I dislike secret clubs, and I fear the reliance on secret clubs provides a false sense of secretivenss. Secrets leak.
If the bug is important enough to warrant an embargo it needs to be fixed ASAP. A month is too long to run with an important vuln in running code. It's always going to be a balance, and as a user not involved in any secret security clubs I want those bugs fixed and in the public space as quickly as reasonably possible.
On the other hand, by publishing the vulnerability, you’re making people running all those other systems more vulnerable. The point of the embargo process is collective security, rather than just the security of your own users. One day, your project of choice won’t be able to fix a vulnerability as quickly as another - and you’ll be left in the lurch then, without an embargo.
Balls were definitely dropped. My understanding of the Lazy FPU event is that (a) someone at Intel asked if OpenBSD signed NDAs and was told no, then shrugged their shoulders and didn't pursue it any further; and (b) someone at OpenBSD tried to get in touch with Intel, but didn't talk to the right people (Intel is very siloed), and didn't get anywhere.
I've witnessed conversations since then between Intel people and FreeBSD people basically consisting of FreeBSD people saying "you guys really need to include OpenBSD" and Intel people saying "yeah... can you help get us connected with the right people?" so I don't think it's fair to suggest that OpenBSD is being purposely excluded.
Is OpenBSD supposed to comply with secret terms
I think that OpenBSD should follow the norms of the security community, i.e., contacting other operating system vendors and coordinating disclosures -- regardless of how they come across a vulnerability.
So that one day they might get invited to the cool kids secret club?
Not breaking embargoes doesn't seem to have done that for them yet.
Instead we get people like you FUDing about how they are unable to keep secrets and are justifiably being blocked from information.
I'd rather they look out for me, a user, than get the worst of both worlds, just because one day it might pay off.
these kind of memes last literally forever, in 10 years they will still be talking about how OpenBSD "broke" the KRACK embargo, and we shouldn't tell them anything.
> Is OpenBSD supposed to comply with secret terms that they are purposely not made aware of, nor have agreed to?
You discovered the secret, but recognize that embargoes still have value even if you weren't part of it. Be the better project, show magnanimity, and don't place end users of other projects at undue risk.
> That's a pretty unfair standard don't you think?
I agree that 12 month embargoes are stupid. I know that there are people, including FreeBSD people, who have been vigorously encouraging Intel to be more reasonable about how such issues are handled.
I played a small role in that after Theo announced the Lazy FPU issue, by writing exploit code and telling Intel (via the FreeBSD people in the embargo) "shorten the embargo or else".
Given how much Intel likes to throw their weight around wrt embargo terms well past the point of being unreasonable, maybe it's a good thing that someone holds a gun to their head every once in a while.
If you want to lead market in mission-critical product, there's a certain amount of responsibility that you have to your customers and more than once Intel has lost sight of that.
> it was "let's publicly disclose the vulnerability at the soonest opportunity".
> ...
> he has made it clear that he isn't interested in acting as a productive member of the community.
Don't project your opinions about disclosure to other people and their intentions.
Responsible disclosure is a scam that puts vulnerability researchers, downstream project maintainers and users in the position of being malicious actors all while absolving those responsible from their responsibility.
Immediate and public disclosure is the only responsible disclosure there is and I commend (and monetarily contribute to) the OpenBSD Project for their soft stance against embargoes.
Operating in opposition to that, a large portion of the security industry plays along for reasons varying from personal pride (appealing to authority makes you feel like one of the good guys) to the extremely lucrative payouts for selling 0day to nation states. It's no surprise that the higher your profile in the industry and on twitter, the easier time you have getting paid out on bug bounties. All of this hurts users.
I develop and maintain software and software infrastructure for a living. If you find a vulnerability in work I am responsible for, please rake me over the coals as publicly and loudly as you can. That motivates the PTB who fund my work to resolve the issue better than anything else.
Google's policy seems about right to me. When they discover a security flaw in someone else's software, they give them 90 days before making it public [0]. The choice of 90 days is to strike a balance between applying strong pressure to the company to get it fixed fast, and giving them a reasonable amount of time to get it done and rolled-out. My understanding is that this approach generally works fairly well.
You'd rather that they adjust that notice period all the way down to zero, and hand vulnerabilities over to the bad guys for free right out of the gate?
You are assuming that the white hat security researcher was the first to discover the flaw. That is a perfectly reasonable assumption, and your position is perfectly reasonable given that assumption.
GP was assuming that the white hat security researcher was not the first to discover the flaw, and that the flaw is actively being used to attack users. That is a perfectly reasonable assumption, and GP's position is perfectly reasonable given that assumption.
That's still not enough. Even if bad guys are already using the exploit in the wild, it still isn't responsible to immediately make it public. If the exploit isn't already public, that means the bad guys are treating it as something to be traded in secret. (And of course, the only reason we're discussing this is that the exploit is not already public.)
Instantly publishing the details of the exploit may well broaden its use by bad actors, by reducing its market price to zero.
There are dedicated teams of people who are highly skilled, well-funded and working full time at finding exploits with the intent of selling or using them.
The bad guys already have the vulnerabilities long before the good guys do.
Lower-skilled criminals and script kiddies who are relying on disclosure before they can do anything are far less ambitious and do far less damage.
Stuxnet and recent high-profile banking malware all employed legitimate 0day and did real damage to people. Vulnerability disclosure contributed nothing towards that.
But I'm not saying this to convince you, I'm saying this to keep my stuff secure. Google doesn't choose 90 days out of a sense of anything other than what's good for Google and its shareholders.
There's a serious bug that impacts a number of operating systems, including OpenBSD. In order to coordinate a release, some vendors were made aware of the bug before it was publically disclosed, but OpenBSD was not one of them, probably because OpenBSD has a reputation (fairly or not) as being very anti-secrecy, not being cooperative in situations like this, and not providing other vendors advance notice of issues they find.
OpenBSD is, understandably, upset that they ended up shipping a bug when they could easily have delayed the release had they been made aware of it. Whether that's a legitimate complaint, or simply their just deserts given their past behaviour, or somewhere in between is something I'm not remotely qualified to answer.
In any case, if people won't trust you to follow embargoes, you'll end up shipping bugs, and angrily complaining on public mailing lists that people don't trust you won't make people start trusting you. (For one thing, notably absent from the linked post was a "we would have course adhered to the embargo if we'd been asked", which leaves the question open of whether not trusting them, in this specific case, may not have been correct. In any case, this will be resolved, if it's resolved, in private between concerned individuals.)
To add a wrinkle that may be missed from a quick read of Theo’s post: OpenBSD’s X maintainer is on the X.org security team - that’s the Matthieu referenced.
So it’s possible that an entirely human set of mistakes occurred that lead to this happening; it’s also possible that embargoed bugs came in to play.
Alternatively, if it is a trust issue, the fact that it's not just "the X.org security team doesn't trust the OpenBSD maintainer team" but "the OpenBSD X maintainer doesn't trust the rest of the OpenBSD maintainer team" adds several extra levels of politics to this, which I suspect is what Theo was alluding to with his "abdication of the duty of care" comment.
I assume Matthieu acted (if that is indeed what he did) in his role as a member of the X security team, but I imagine Theo would say that in doing so he failed to act appropriately in his role as a member of the OpenBSD maintenance team. It all makes me quite interested to know what his reasoning was.
Excerpt from the "Official Dangerous Virus Notice" Distributed at the X-Windows Conference:
>This is what happens when software with good intentions goes bad. It victimizes innocent users by distorting their perception of what is and what is not good software. This malignant window system must be destroyed.
>Ultimately DEC and MIT must be held accountable for this heinous software crime, brought to justice, and made to pay for a software cleanup. Until DEC and MIT answer to these charges, they both should be assumed to be protecting dangerous software criminals.
>Don’t be fooled! Just say no to X.
>X-Windows: …A mistake carried out to perfection. X-Windows: …Dissatisfaction guaranteed. X-Windows: …Don’t get frustrated without it. X-Windows: …Even your dog won’t like it. X-Windows: …Flaky and built to stay that way. X-Windows: …Complex non-solutions to simple non-problems. X-Windows: …Flawed beyond belief. X-Windows: …Form follows malfunction. X-Windows: …Garbage at your fingertips. X-Windows: …Ignorance is our most important resource. X-Windows: …It could be worse, but it’ll take time. X-Windows: …It could happen to you. X-Windows: …Japan’s secret weapon. X-Windows: …Let it get in your way. X-Windows: …Live the nightmare. X-Windows: …More than enough rope. X-Windows: …Never had it, never will. X-Windows: …No hardware is safe. X-Windows: …Power tools for power fools. X-Windows: …Putting new limits on productivity. X-Windows: …Simplicity made complex. X-Windows: …The cutting edge of obsolescence. X-Windows: …The art of incompetence. X-Windows: …The defacto substandard. X-Windows: …The first fully modular software disaster. X-Windows: …The joke that kills. X-Windows: …The problem for your problem. X-Windows: …There’s got to be a better way. X-Windows: …Warn your friends about it. X-Windows: …You’d better sit down. X-Windows: …You’ll envy the dead.
This is much more interesting than all of this soap opera about Theo.
What we see in this commit, regression, and vuln is that the X server is an enormous setuid program with tons of code and zero tests. The "fix" also does not contain any tests that could have detected the problem, so it's just a continuation of what is now a quarter-century of bad software engineering practices.
X was built on false assumptions of what the future would look like (dumb terminals). The whole thing is a massive hack around its server/client architecture - which does not work well with modern graphics hardware.
It’s no small part of why Linux has failed on the desktop.
In short, lack of tests are the least of its problems.
Well, it looks like they have a patch [syspatch64-001_xserver] not sure which fix they chose.
[edit] a tweet for @OpenBSD said: We're currently preparing errata and a security advisory for today's Xorg issue that allows arbitrary overwriting of files as a non-root user. You can run "chmod u-s /usr/X11R6/bin/Xorg" as a temporary workaround until the fixes are out.
From the RH bug report (https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2018-14665), this is described as “an incorrect permission check for -modulepath and -logfile options when starting X.Org,". Would wayland be immune to these kinds of things, or is it not relevant here ? And is OpenBSD planning to switch to wayland ?
This vulnerability can be mitigated if you don't run X as root. Use the modesetting driver and ensure permissions to the video device with Unix groups or a mechanism like systemd-logind.
Since Wayland compositors are almost never setuid root, it isn't a problem for them.
The only reason the researcher gave permission was because the OpenBSD devs said that they were going to release on the original embargo date instead of extending out to 90 days like everyone else agreed to. They even say on their mailing list that they probably announced too much with their errata when they "silently" patched it. They techincally didn't break the embargo, but only because they refused to go along with what the rest of the community was doing.
> The only reason the researcher gave permission was because the OpenBSD devs said that they were going to release on the original embargo date instead of extending out to 90 days like everyone else agreed to.
Do you think it unreasonable for one project to strongly push back against a 180 day embargo? How about a year embargo? Two years? Is there any point where a project can say, “We believe extending the embargo beyond what we’ve agreed to is going to keep our users unpatched, and won’t succeed at keeping the bug secret, so we’d like your permission to release according to the schedule we agreed to,” or is that verboten since it’s not “going along with the rest of the community”?
as I read it, it seems openbsd's X maintainer, matthieu herrb, knew about it but didn't tell theo or the other openbsd devs. that seems strange, and not really related to early access.
If OpenBSD starts participating in embargoes, they'll get advance notice of vulnerabilities. It's as simple as that.