If OpenBSD starts participating in embargoes, they'll get advance notice of vulnerabilities. It's as simple as that.
I don't know if it would actually work, but that would at least put responsibility for handling this on Theo.
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.
This actually sound quite reasonable to me.
No atom in their body is even the same. (Supposedly.)
Replying to him in the thread is Ted Unangst, a high-profile OpenBSD developer.
You mean that OpenBSD discovered this issue by themselves when they were left out of an ongoing embargo?
Please explain to me how one can break an embargo they are not a part of in the first place?
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.
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.
[edit: It's probably more accurate to say that Theo doesn't want to agree to an embargo.]
Given that nobody here seems to be able to point to a single embargo that has been broken, how exactly do you propose he do that?
> 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."
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.
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.
Don't project your opinions about disclosure to other people and their intentions.
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?
[0] https://arstechnica.com/information-technology/2015/02/googl...
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.
Instantly publishing the details of the exploit may well broaden its use by bad actors, by reducing its market price to zero.
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.
“Said that they were going to”? More “expressed a desire to.” And that was a reasonable desire—so reasonable that the researcher willingly agreed, if reluctantly. https://marc.info/?l=openbsd-tech&m=152909822107104&w=2
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”?
https://marc.info/?l=openbsd-tech&m=152909822107104&w=2
("Mathy" is the researcher who discovered KRACK.)
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.)
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.
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.
It’s no small part of why Linux has failed on the desktop.
In short, lack of tests are the least of its problems.
Since Wayland compositors are almost never setuid root, it isn't a problem for them.
>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.
https://medium.com/@donhopkins/the-x-windows-disaster-128d39...
[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.
I guess that by doing the type of discussion in the public, the level of accountability is a lot higher for all concern.
