The researcher's reaction is correct. OpenBSD maintainers' lack of patience may have led to this vulnerability being discovered and exploited by other people.
In other words, its malfeasance by the security community for holding out.
There's only a few courses of actions. One is to sit quietly and let everyone eventually do the solution. And that doesn't work. No fire under peoples' asses, and the work is delayed.
The other, is to release it promptly. Then, at least we can decide to triage by turning down X service (even if wifi), requiring another factor like tunnel-login or what have you.
But truthfully, defect in a Prisoners Game played out here was the best choice. The rest of the community is "agree".
No one should care about a community that agrees that releasing silent patches is a good idea. This is exactly the same behavior that created the need for full disclosure in the first place. And no, there aren't just two options nor are processes binary. It's rather mind boggling how "the community" has managed to go full circle in such a short time and themselves become the opinionated people they were supposed to be the alternative to.
As far as I understood, this attack has no client-side mitigation that could be employed other than treating every wifi as an open network. The attack might already be known to hostile actors or may have become known during the embargo, but full disclosure without an embargo would guarantee that clients are at risk without mitigation. An embargo at least gives time to prep patches and protect at least a portion of the clients.
Either there is a possibility for patches to be prepared during an embargo or there is “no client-side mitigation”, you can’t have both. From reading the rest of this thread, it appears that it is quite possible to patch this on clients such that, if you are using a patched client, you are safe. Disclosing earlier would have lead to more people having patched clients earlier and hence being safe.
Patching the client is a fix. Mitigation would bea config setting that makes me safer (disable some unused functionality,...). So yes, you can have both.
That’s like saying that prior to introducing seatbelts, we should have allowed for a period of time to glue people to their seats because it is preferable to have a mitigation they can apply themselves than a fix the manufacturer has to put in.
If you don’t limit mitigation to "a config setting" (and why would you?!), a patch/new version is the best mitigation you can get.
I limit mitigation to a config setting because that’s what affected clients can do in this case. Everyone patching wpa_supplicant on their android handset is just not going to happen and it takes time for vendors to roll out patches.
> As far as I understood, this attack has no client-side mitigation that could be employed other than treating every wifi as an open network.
I've been doing that for years and recommend others do so as well.
The rise of HTTPS nearly everywhere helps mitigate things a bit. This same type of exploit 5 years ago would wreak havoc exploited at the local Starbucks WiFI.
You got everything wrong. If big vendors are unable to patch their proprietary products in an acceptable time, that shouldn't put others at risk. Users shouldn't choose their products...
Think about it in a different way:
What if a vulnerability was discovered in TLS and FOSS implementations patched it, but there is an embargo for supposedly protecting some banking software? What if NSA/CIA/other agencies find out about it (they would know immediately) and use it to target users/activists?
This is why embargoes have deadlines. To make the necessary trade-off between "patch as soon as you can, potentially jeopardising the safety of users -- even users of non-proprietary projects" and "wait for everyone to be ready before you patch -- which also jeopardises users". The embargo system deals with this by forcing everyone to agree on a date, and if someone patches after that date then too bad. You may disagree that the deadline was so long, and that could be a fair criticism.
But pretending as though co-ordination of any kind is somehow bad (and then resorting to emotional arguments and so on) is pretty reckless.
I have seen and participated in this disclosure debate for 10 years now. I have come to the conclusion that, in the long run, the least harm approach is full disclosure. There isn't any wiggle room. There are no shades of grey. The whole coordinated response movement is misguided. There are some limited circumstances where it can make sense to delay disclosure, such as creating an imminent threat to human life, but generally full and nearly real time disclosure results in safer software sooner for end users without putting them at some unknown, but high risk level.
3 months is more of a joke than a reasonable time, but one can argue about that if he wants...
> even users of non-proprietary projects
Actually many FOSS projects get only notified on the disclosure date.
Hiding the vulnerability for such a long time makes more harm good. The vulnerability can potentially be exploited by security agencies that necessarily know about them and could also be leaked to a bad actor by an employee of one the vendors.
Hopefully WPA2 isn't that important, but potentially security sensitive users trusted something that was known by some to be vulnerable for 3 months! Bad actors could have used it against them.
The embargo resulted in potentially bad actors knowing about the issue, but not vulnerable users.
The state actor should be least of your worries compared to the millions of script kiddies would could use the vulnerability once it is disclosed publicly.
For most of them the day after, when I get a notification from my RSS app...
No. I also don't expect them to choose device based on security. That is very bad as vendors won't care about patching their older devices (look at Android devices, home routers...) and vendors won't care about patching their flagship devices fast as they have the possibility to request very long embargos.
Making compromises for those vendors and giving more time for security agencies and other bad actors to silently exploit the vulnerabilities (where FOSS projects would have made patches for users that care) is not the way to go. That philosophy actually makes everybody less safe.
What if [...] is FUD. What if Theo de Raadt works for the FSB? We need to work with the facts.
If you don't agree with an embargo and decide to break it, that's on you. But the consequence is that you shouldn't be surprised if next time you're informed later, or not at all. What OpenBSD proponents and developers are doing right now, is damage control. It may work this time, it may work next time, but it won't keep working every time so pick your fights right. It isn't the first debacle OpenBSD has with full disclosure either (hint: OpenSSH).
There are also millions upon millions of devices which won't get patched. Given the vulnerability is apparently the most vulnerable on Linux and hence Android, do you think all the smartphones running Android 4.3, 4.4, 5.0, and 6.0 will be patched [1]?
No, I don't. And its stupid, because it doesn't have to be that way. But telecoms have complicated the situation with their greedy firmware reinforced planned obsolescence.
