Hacker News Reader

Comment by claudius | Hacker News Reader

The researcher’s lack of full disclosure may have lead to this vulnerability being discovered and exploited by other people.

View on HN

Also an embargo lasting months seems excessive.

You also can not guarantee me that no one who gets this information early is not working for a bad actor.

I'm just so glad this long embargo meant that everyone had patches ready to go as soon as it expired! Oh wait, they don't. Good job CERT.

I wonder when the NSA and CIA was responsibly informed about this vulnerability.

OpenBSD wifi maintainer here.

I was informed on July 15.

The first embargo period was already quite long, until end of August. Then CERT got involved, and the embargo was extended until today.

You can connect the dots.

I doubt that I knew something the NSA/CIA weren't aware of.

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.

Really makes me wish you'd told the world. I know all the arguments against that, but this sort of thing is no good either.

Yes, but that would result in them not getting notified for any other vulnerability.

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.

Reply on news.ycombinator.com