> OpenBSD was notified 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.
I'm not convinced it was a bad decision. Why would you want to leave your users vulnerable? It's possible that this has been exploited in the wild.
Up until now, there were no indications that this was being exploited publicly. After a flaw like this gets known (whether through a coordinated disclosure or through OpenBSD's early patch) you can be assured people will be exploiting this.
Do you both stay silent and take the minor risk of your users being vulnerable for a short time longer whilst patching and disclosure is being coordinated with all parties (-1/-1), or do you "betray party B" but get your own users secured as soon as possible (-3, 0).
I think coordination makes more sense in a flaw as big as this.
This probably hasn't been exploited in the wild. Anyway the point of coordinating disclosure is to leave fewer people vulnerable overall. If one team releases a patch early, attackers can analyze the patch and start using the vulnerability against unpatched systems. Waiting for everyone to patch at once closes that window.
How can you state that it probably hasn't been exploited in the wild with any degree of confidence? It's possible that the same flaw was found and exploited years ago by black hat hackers and/or state security services. We have no way to know whether this actually happened, or even estimate the probability.
Because it hasn't been seen before, it's not likely that it has been exploited. Even after knowing about the flaw for a while, the Wi-Fi Alliance says there is no evidence that this was used maliciously before. https://www.wi-fi.org/news-events/newsroom/wi-fi-alliance-se... We can't know absolutely but with all the attention wifi has gotten since the days of war driving, there's a good chance it would have been caught.
Yeah, without the alliance stating what methods were used to look for attacks, its hard to take that seriously... it's the same line used in just about any security breach.
Is this attack likely to generate log evidence on affected APs in their default configuration, or is it so far down the stack that no evidence is generated and nobody could refute this claim?
I'm not convinced it was a bad decision. Why would you want to leave your users vulnerable? It's possible that this has been exploited in the wild.