93

KRACK Attacks: Breaking WPA2 | Lobsters

 6 years ago
source link: https://lobste.rs/s/dwzplh/krack_attacks_breaking_wpa2#c_pbhnfz
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

KRACK Attacks: Breaking WPA2

TL;DR:

I found this note about OpenBSD issuing a silent patch ahead of the embargo date somewhat amusing:

To avoid this problem in the future, OpenBSD will now receive vulnerability notifications closer to the end of an embargo.

  1. stsp

    OpenBSD Developer

    4 years ago

    | link

    No worries. We will likely still patch on time of public announcement anyway. We just cannot patch problems we don’t know about yet.

    What happened is that he told me on July 15, and gave a 6 weeks embargo until end of August. We already complained back then that this was way too long and leaving people exposed.

    Then he got CERT (and, thus, US gov agencies) involved and had to extend the embargo even further until today. At that point we already had the ball rolling and decided to stick to the original agreement with him, and he gave us an agreeing nod towards that as well.

    In this situation, a request for keeping the problem and fix secret is a request to leave our users at risk and exposed to insiders who will potentially use the bug to exploit our users. And we have no idea who the other insiders are. We have to assume that information of this kind leaks and dissipates pretty fast in the security “community”.

    We chose to serve the needs of our users who are the vulnerable people in this drama. I stand by that choice.

      1. What is the rationale on extending the embargo so long? To give vendors a chance to patch? It seems like once people in the know know about a vulnerability, the shorter an embargo time the better.

        1. stsp

          4 years ago

          | link

          There’s a couple of different interests at play.

          For instance:

          Researchers want to make a timed media splash.

          Security agencies want to evaluate the problem and make sure they get patched before anyone else.

          Vendors want time to prepare patches, yes, but that alone does not justify such a long delay.

          Reviewing the patch, testing it, and preparing it for commit and publishing erratas took only a couple of hours of my free time.

        2. From July 15 to today is about 90 days which is far from unreasonable for co-ordinated disclosure. Project Zero use a 90 days + 2 week for patch release in their policy.

          1. Which still doesn’t sound nice, though. Over three months of hoping that nobody who was informed and has any malicious intent and that nobody rediscovers it and nobody that might have discovered it earlier.

            Now while WPA2 will in most cases require you to be physically close to exploit a lot of remote vulnerabilities mean that anyone hearing about it has over three months to scan the whole internet. And that’s a process that might take just some hours with tools like zmap.

            For stuff like finance, healthcare, etc. 3 months of “free access” seem everything but reasonable, regardless of what any project does.

            Coordination is a good thing. Maybe however making this processes faster is a good idea. Currently people are assuming that all insiders (known or unknown) have just the best intents. This feels very unreasonable. As an entity intending to exploit vulnerabilities this is probably one of the first circles I’d want to get into.

            I am not an OpenBSD user, but I think stsp/the OpenBSD project didn’t do anything wrong, by sticking to an original deadline, as well as considering the deadline as too long. At least for said vulnerability. It should be a per-case decision though, since routers aren’t browsers that you nowadays can just kick out updates for.

    1. Thanks to you and yours for putting users first.

    2. FWIW, I think you made the right choice. Appreciate the integrity and concern for users overriding the institutional politics.

      1. On the other hand this kind of behaviour tend to reduce trust with security researcher. They should not complain once they get notified last for the next critical security disclosure. Unless someone has proof this was exploited in the wild, patching a security bug involving many stakeholder might put your users first, but put all the other system’s users at risk.

        1. stsp

          4 years ago

          | link

          involving many stakeholder

          How can anyone be certain that all of these many stakeholders are trustworthy and won’t abuse the secret information they have?

          1. How can anyone be certain that all of these many stakeholders are trustworthy

            You don’t, but the call is not yours to make. If they see them as not trustworthy, it’s the security researchers to chose notify those stakeholder closer to the end of the embargo.

            Find your own bug and choose to go full disclosure if you want to, but OpenBSD have no part in finding this security issue, they were trusted by someone else to hold on a patch (for 90 days FFS). By acting the way they did they only showed that they could not be trusted with this privileged information.

            1. stsp

              edited 4 years ago

              | link

              It’s easy for you to say that, not having been in a situation where you had to actually make that choice yourself.

              It seems you would trust the NSA/CIA to not abuse a bug like this? I wouldn’t.

              Edit: Also, let me reiterate that: WE WERE GIVEN PERMISSION BY MATHY TO DO THIS.

              1. Yeah, it seems weird of Mathy to give permission to release early, then punish (not notify as soon as others) anyway. What the hell?!


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK