This a copy of internal discussion between me, Theo, and Mathy Vanhoef about KRACK, from the initial message I received from Mathy, up to today.
I am making this public with Theos's and Mathy's consent, without redaction. I have annotated quoted blocks with names to make the discussion a bit easier to follow. Mathy's approval of my commit is documented below. If you hear people claiming OpenBSD (and by extension, me personally) broke the KRACK embargo, then please point them to this so they see I was given permission to commit the fix. If I remain a villain in their minds after reading this, I won't try to convince them any further. I don't do shouting matches. ----- Forwarded message from Mathy Vanhoef <mathy.vanh...@cs.kuleuven.be> ----- Date: Fri, 15 Jun 2018 22:32:15 +0200 From: Mathy Vanhoef <mathy.vanh...@cs.kuleuven.be> To: Stefan Sperling <s...@openbsd.org> Subject: Re: [dera...@openbsd.org: Re: Key reinstallation attack against WPA1/2 resulting in nonce reuse]] X-Spam-Level: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-ID: <0e9828ceae1236b0571745540313e...@cs.kuleuven.be> User-Agent: Roundcube Webmail/1.2.9 X-Spam-Score: (-2.004) BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL [mathy] > > The security advisory released on 30 Aug 2018 wasn't explicitly > > agreed, > > only releasing the silent patch. So this was unexpected. Though I > > don't > > recall which details were included in this early advisory. [stsp] > For the record, this is the initial commit to -current: > https://marc.info/?l=openbsd-cvs&m=150294967228872&w=2 > > With diff: > https://github.com/openbsd/src/commit/2e40dd69ac29d6a858309bce0e05e65eec66648f#diff-4cf043b0a21146c45238a2c964206909 > > To reiterate, we had no idea where information about the bug was going to > spread between Aug 14 and Oct 16. Given the wide impact, the many parties > involved, and the long time frame of an additional 2 months, a leak into > circles which would try to abuse this information was possible. > The process was now trundling outside your own control and, in my opinion, > exceeding reasonable risk dimensions. > > Theo and I didn't want to wait much longer, knowing if users running > OpenBSD > releases got targeted e.g. by industry/government insiders or as a result > of leaks from the embargo process, we would be partly responsible. > We carefully issued an errata on Aug 30 (the originally agreed time > frame). > No impact beyond OpenBSD could be discerned from our errata patch. > The errata description was designed to imply an implementation-specific > bug. > https://ftp.openbsd.org/pub/OpenBSD/patches/6.1/common/027_net80211_replay.patch.sig > > Your name was kept off all of this to avoid drawing attention to your > research in this context. Since we had collaborated before on the > WPA1/TKIP > issue, mentioning your name would have given away the fact that > independent > research had occurred. > > I would argue that this still conforms to our "silent patch" agreement, > though I would understand if in your opinion we stretched it a little. > An errata does send a strong signal that something is wrong. However, a > major goal of the embargo was to avoid early exposure of the fact that > the industry at large was affected, and we evidently didn't expose this. > There were no public news reports of the problem before your announcement. > And if you hadn't specifically highlighted OpenBSD in your announcement, > chances are very few people would have noticed the timing of our patch > (https://www.krackattacks.com/#openbsd, which BTW we weren't asked to > comment upon before it was made public -- that would have been nice and > might have avoided some public drama we had to endure). [mathy] Many people interpreted the OpenBSD FAQ in a manner that I did not intend. So that could have been written better. My intention was to mention there were different opinions about disclosure timelines. Then I gave the OK to push a silent patch (so this was effectively my decision). In future disclosures I will probably not give anyone the OK to push a silent patch in advance. One thing that's unclear to me is how much in advance OpenBSD would want to be notified in the future if there is a coordinated disclosure? Because there appears to be discomfort with knowing there is a vulnerability, but having to wait a relatively long time before deploying it? On this topic, it is also worthwhile to mention that Microsoft pushed their fixes on patch Tuesday on 10 October 2016 [1]. That's before the agreed disclosure deadline, albeit quite close in time. This was only for their rather low-impact vulnerability CVE-2017-13080. Their Security Update Guide was only updated on October 16 to provide full details. [1] https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-13080 [stsp] > Your implementation-independent source code comments with details > about the bug were added only after the Oct 16 embargo had expired: > https://github.com/openbsd/src/commit/cc66e8f557d6f3d4dea5ea60b4d332d744b651c3#diff-4cf043b0a21146c45238a2c964206909 > I apparently forgot to credit you in the commit message there, > which I should have done; sorry about that. [stsp] > > > Of course, explaining our viewpoint on the KRACK story won't magically > > > fix the problem with Intel. But as the developer who dealt with KRACK > > > at OpenBSD's end, I have a personal interest in at least setting the > > > KRACK record straight. > > > > > > Below is a private email Theo sent to some of them, and apart from mail > > > were Theo was in Cc it also includes a private response from you to me > > > which I've now shared with Theo to help him understand your viewpoint, > > > on the condition that it should not be made public without your consent. > > > > > > I'm writing to ask: > > > Would you mind if the parts below which you wrote were made public? [mathy] > > Can you give some more background on this? E.g. in which context will > > this be made public? Where will this be posted? [stsp] > I would like to forward this message to one of the project's public > mailing lists, e.g. tech@openbsd.org. Because you wrote most of the > quoted text in private mail, I won't do so without your permission. > > My motivation for doing this is that I hope to prove to the public that: > > 1) You agreed that the patch could be committed by me (since apparently > this is still being contested by some people out there, which > tarnishes > my reputation as an independent open source consultant beyond > OpenBSD). > > 2) I didn't act in bad faith from your point of view regarding the > errata (e.g. the part where you said "I can understand this > viewpoint." > in your last email message quoted below) > > I can live with an open public question of whether issuing the errata in > the way we did was reasonable. I don't think there is an obvious answer > to this question. All trade-offs considered, I do stand by this decision. [mathy] Whether issuing an errata was appropriate or not is something that can be discussed (I would have just sticked to only the patch). In any case, I don't believe you acted in bad faith here. [mathy] > > From my point of view, I sent one mail on 14 August where I mentioned > > the new disclosure date of 16 Oct. In that same mail I also gave the > > OK > > to quietly commit a fix. [stsp] > I can include this correction from you as well. [mathy] It's a minor fix, but I suppose it would be the correct thing to do. Regarding my mail on 10 November that includes the "I can understand this viewpoint": the remaining part of this paragraph is me saying in a nice and perhaps too indirect way that I think full disclosure of the KRACK attack would've been a bad decision. [stsp] > Would you mind if I also released the discussion we're having right now? [mathy] That is OK for me. Cheers, Mathy > Thanks, > Stefan > > > > ----- Forwarded message from Theo de Raadt <dera...@openbsd.org> ----- > > > > > > Date: Mon, 11 Jun 2018 12:36:57 -0600 > > > From: Theo de Raadt <dera...@openbsd.org> > > > To: rgri...@freebsd.org > > > cc: dex...@freebsd.org > > > Subject: Re: Key reinstallation attack against WPA1/2 resulting in nonce > > > reuse] > > > Content-Type: text/plain; charset="us-ascii" > > > Message-ID: <39776.1528742...@cvs.openbsd.org> > > > X-Spam-Score: (-2.6) BAYES_00,SPF_HELO_PASS,SPF_PASS,UNPARSEABLE_RELAY > > > [theo] > > > 15 Jul 2018 > > > [1] Initial disclosure. Mathy says probably by end of August. > > > 17 Jul 2018 > > > [2] I argued with Mathy about 1.5 months, really?? can't you do > > > better? > > > Mathy indicates he hopes for earlier. > > > 14 Aug 2018 > > > [3] Mathy contacts CERT, tells us, we ask again... > > > 15 Aug 2018 [in previous mail from me] > > > Mathy says we can commit quietly > > [mathy] > > From my point of view, I sent one mail on 14 August where I mentioned > > the new disclosure date of 16 Oct. In that same mail I also gave the > > OK > > to quietly commit a fix. > > [theo] > > > 17 Aug 2018 [in previous mail from me] > > > stsp commits quietly > > > 30 Aug 2018 [in previous mail from me] > > > "end of august" is reached, we release a security advisory > > > without extensive detail (no information for weaponization) > > > 16 Oct 2018 > > > first time freebsd tells the world > > > > > > https://lists.freebsd.org/pipermail/freebsd-announce/2017-October/001805.html > > > we do not know internal freebsd timelines. don't have a CERT > > > correspondance > > > of our own to connect the timeline. > > > > > > 10 Nov 2018 > > > [4] I am going to share a mail to you after the fact, which I ask you > > > to > > > keep confidential. I never saw this until today. It contains a > > > discussion > > > about FreeBSD being slow to fix, and you can appreciate keeping that > > > private. > > > > > > But the greater point -- if Mathy feels no ill will towards OpenBSD and > > > our repair processes coordinated with him, why have others taken such a > > > negative position? Lacking skin in the game, what is their > > > justification > > > to be more negative than Mathy himself? > > > > > > 16 Nov 2018 > > > Details for POC published at krackattacks.com > > > > > > I think we can see CERT's foot-dragging playing through this. > > > > > > Remember I mention that it doesn't look like CERT told us. Maybe CERT > > > didn't tell OpenBSD because Mathy told them our fix had wound through? > > > Any case it didn't cause them to rush. Mathy probably told other > > > [limited] audiences also upon initial discovery. > > > > > > So the timelines are: > > > > > > after disclosure to openbsd, +1 month we commit, +1.5 months to errata. > > > > > > disclosure to CERT @ +1 month mark. freebsd tells the world at +2 > > > months, which is +3 months after discovery. What happened in those > > > 2 months? CMU toga parties?? > > > > > > I suspect CERT has led the crowd with a misleading story. However I > > > have heard allegations of people representing FreeBSD and other project > > > played along with the meme. If true, that is very dangerous. > > > > > > ---------------------------------------- > > > > > > [1] > > > Date: Sat, 15 Jul 2017 01:37:35 +0200 > > > From: Mathy Vanhoef <mathy.vanh...@cs.kuleuven.be> > > > To: s...@openbsd.org > > > Cc: dera...@openbsd.org > > > Subject: Key reinstallation attack against WPA1/2 resulting in nonce reuse > > > Message-ID: <20170715013735.49841...@cs.kuleuven.be> > > > Content-Type: multipart/mixed; boundary="MP_/j9UeRUZKQkLXab=ecMlC=m7" > > > X-Spam-Score: (-2.004) BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL > > > > > > Hi Stefan, Theo, > > > [mathy] > > > I found an attack against the WPA1/2 implementation open OpenBSD. > > > Simplified, a WPA1/2 client can be tricked into reinstalling an > > > already-in use pairwise key. This is accomplished by manipulating > > > retransmissions of message 3 of the 4-way handshake. While reinstalling > > > the pairwise key, the incremental nonce and replay counter associated > > > to the key are reset. Against CCMP, an adversary can abuse this to > > > replay and decrypt packets. Against TKIP, it becomes possible to > > > replay, decrypt, and forge packets. > > > > > > The problem is that when a client receives a retransmitted Msg3 in the > > > 4-way handshake, it will reinstall the already in-use pairwise key (and > > > for WPA2 it will also reinstall the already in-use group key). Note > > > that the AP retransmits Msg3 if it did not receive Msg4. Hence an > > > attacker can trigger retransmissions of Msg3 by blocking the arrival of > > > Msg4. When the client reinstalls the already in-use key, the nonce and > > > replay counter used by either TKIP or CCMP are reset. Hence the client > > > will subsequently reuse nonces when sending frames protect using TKIP > > > or CCMP, meaning keystream is reused (allowing decryption of packets). > > > Against TKIP this decryption attack can be further abused to recover > > > the MIC key, which in turn can be used to forge packets. Since the > > > replay counter is also reset for both CCMP and TKIP, frames sent > > > *towards* the client can also be replayed. > > > > > > A similar attack is possible against the group key handshake. A > > > retransmitted group message 1 will reinstall the already in-use key. > > > This allows an attacker to replay broadcast and multicast frames to the > > > client. > > > > > > The attached file patch_key_reinstall.diff is a proposed fix. This > > > assures that that a pairwise key is only installed once during a > > > specific 4-way handshake. Additionally, it prevents the reinstallation > > > of an already in-use group key during both the 4-way handshake and the > > > group key handshake (otherwise group key handshake messages can be > > > manipulated to trick clients into reinstalling the group key, and hence > > > lower or reset the associated replay counter). Maybe it's a good idea > > > to put the repeated group key installation code in a new function > > > though! More details about the group key reinstallation attack can > > > always be provided (e.g. a simple PoC using a modified Linux AP). > > > > > > Without going into detail, some tricks are needed to attack the 4-way > > > handshake as implemented in OpenBSD. In particular, once an OpenBSD > > > client installs the pairwise key, it only accepts retransmissions of > > > Msg3 that are encrypted using TKIP/CCMP. This means an ordinary > > > retransmission of Msg3, which is not encrypted, cannot be used to carry > > > out the attack. However, I found a technique against Linux's hostapd AP > > > and kernel, that can be abused to trigger retransmissions of Msg3 that > > > *are* encrypted using TKIP/CCMP. OpenBSD will accept these encrypted > > > retransmissions of Msg3, and in response will reinstall the pairwise > > > key (and group key). Further details can always be provided, but the > > > summary is that OpenBSD is indeed vulnerable in practice. > > > > > > To *simulate* the above attack, see the attached file poc_openbsd.diff. > > > It will make the AP retransmit encrypted Msg3's, which makes the client > > > reinstall keys (like in a real attack). When my suggested patch is > > > applied to the client, the PoC no longer works. An example of the > > > attack is included in attack-example.pcapng. The network is called > > > "simulnet", with as passphrase "password" (without quotes). Notice that > > > due to the attack the client (1) accepts an already used CCMP replay > > > counter (IV) in retransmitted Msg3's, and (2) reuses the CCMP IV 1 when > > > transmitting Msg4's due to the reinstalled key. > > > > > > These attacks also affect other products/vendors. Hence I want to > > > coordinate the vulnerability disclosure, so that all affected parties > > > have a chance to prepare patches. Preferably, the fixes/patches are > > > ready before the end of august. > > > > > > Kind regards, > > > Mathy > > > > > > [diff included] > > > > > > ---------------------------------------- > > > > > > [2] > > > Date: Mon, 17 Jul 2017 15:19:53 +0200 > > > From: Mathy Vanhoef <mathy.vanh...@cs.kuleuven.be> > > > To: Theo de Raadt <dera...@openbsd.org> > > > Cc: s...@openbsd.org > > > Subject: Re: Key reinstallation attack against WPA1/2 resulting in nonce > > > reuse > > > X-Spam-Level: > > > Message-ID: <20170717151953.3164f...@cs.kuleuven.be> > > > Content-Type: text/plain; charset=US-ASCII > > > X-Spam-Score: (0.596) BAYES_50,SPF_HELO_PASS,SPF_SOFTFAIL > > > [mathy] > > > > > ready before the end of august. > > > > [theo] > > > > Are you really calling for 1.5 months? > > > [mathy] > > > I hope it can be released earlier, it's a worst case deadline. I'm now > > > awaiting the responses of other parties, to see by when they can have > > > patches ready. Will update when I have a better overview of this. > > > > > > > > > ---------------------------------------- > > > > > > [3] > > > Date: Mon, 14 Aug 2017 22:25:19 +0200 > > > From: Mathy Vanhoef <mathy.vanh...@cs.kuleuven.be> > > > To: Stefan Sperling <s...@openbsd.org> > > > Cc: dera...@openbsd.org, ke...@openbsd.org, t...@openbsd.org, > > > kette...@openbsd.org, t...@openbsd.org > > > Subject: Re: Key reinstallation attack against WPA1/2 resulting in nonce > > > reuse > > > X-Spam-Level: > > > Message-ID: <20170814222513.260c8...@cs.kuleuven.be> > > > Content-Type: text/plain; charset=US-ASCII > > > X-Spam-Score: (-0.515) BAYES_05,SPF_HELO_PASS,SPF_SOFTFAIL > > > > > > Hi Stefan, > > > [stsp] > > > > At the bottom you will find my patch which is based on your suggested > > > > patch. > > > > Mine implements the same logic. I have just refactored things a bit, > > > > made > > > > some style tweaks, and added comments which document the attack vectors. > > > > Please review my patch and let me know if you spot anything wrong. > > > [mathy] > > > At first sight those patches look OK. I will test them in detail in the > > > next few days! > > > [stsp] > > > > I'm adding some more developers to Cc to hopefully get their opinions, > > > > testing, and review. > > > > > > > > When can we commit a fix for this? Ideally, I would like to commit the > > > > fix > > > > as soon as I have an OK from other developers. I would use an innocuous > > > > log message and, for now, exclude the source code comments which mention > > > > the attack vectors. > > > > Once the issue is made public, I will commit the comments, give you > > > > credit > > > > in the corresponding log message for that commit, and release errata > > > > patches for OpenBSD 6.1 and 6.0. > > > > > > > > Is that OK from your side? If not, then I have the following questions: > > > > Is the embargo until end of August being upheld by other parties? > > > > When can we expect to be notified of an exact disclosure date and time? > > > [mathy] > > > Today I contacted CMU CERT (cert.org) to help coordinate the > > > vulnerability disclosure. That's because more parties are affected by > > > variants of this attack than I initially assumed, and it's infeasible > > > to contact them all on my own.. > > > > > > Basically I'm now waiting for them to (hopefully) help coordinate this. > > > That said, the disclosure deadline is likely postponed to 16 October. I > > > know this is still a while. Therefore, for me it's OK if you "silently" > > > commit a fix for this with an innocuous log message etc. Then on the > > > disclosure deadline (which will be set in stone soon but likely 16 Oct) > > > you can make the issue public like you mentioned. > > > > > > Cheers, > > > Mathy > > > > > > ---------------------------------------- > > > > > > [4] > > > Date: Fri, 10 Nov 2017 16:49:57 +0100 > > > From: Mathy Vanhoef <mathy.vanh...@cs.kuleuven.be> > > > To: Stefan Sperling <s...@openbsd.org> > > > Subject: Re: Key reinstallation attack against WPA1/2 resulting in nonce > > > reuse > > > X-Spam-Level: > > > Message-ID: <20171110164957.587e3...@cs.kuleuven.be> > > > Content-Type: text/plain; charset=US-ASCII > > > X-Spam-Score: (-2.004) BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL > > > [mathy] > > > To finally reply to this: > > > [mathy] > > > > > And to avoid any confusion: if I ever find another issue, you will > > > > > still be notified in advance with enough time to inspect the issue and > > > > > get patches ready! I'll just avoid the "2 months or more in advance", > > > > > and send it say a month in advance. If that's OK. In any case, it's > > > > > unlikely I'll find a general bug like this again, so probably doesn't > > > > > matter anyway, but just to be clear. > > > > [stsp] > > > > I think you should choose full disclosure next time. > > > > > > > > You put us in a conundrum. We knew there was a problem and how to fix > > > > it. > > > > And when you got CERT involved, we had to assume that information about > > > > the > > > > problem was now leaking beyond your control into government agencies and > > > > private companies, and that some of those "in the know" would have had > > > > 2 months of extended embargo time to use an exploit against OpenBSD > > > > users. > > > > I don't see any reason to trust every single person in those parts of > > > > the > > > > security community and in these institutions to act responsibly. > > > [mathy] > > > I can understand this viewpoint. If we did full disclosure, I wonder > > > how everyone would react though. Generally I'd expect quite some > > > backlash, which I doubt my university would appreciate.. there are > > > annoyingly many parties invovled. > > > [stsp] > > > > In spite of the embargo not all vendors had patches ready by the > > > > deadline. > > > > For example, FreeBSD was either lazy or was caught by surprise. > > > > It took them a whole day to release patches and at time of disclosure > > > > they seemed to be unaware and unsure how long these patches would take: > > > > https://lists.freebsd.org/pipermail/freebsd-announce/2017-October/001805.html > > > > Their patches were released a day late: > > > > https://lists.freebsd.org/pipermail/freebsd-announce/2017-October/001806.html > > > > I have not talked to them so I don't know how this happened. > > > > Did nobody tell them? > > > [mathy] > > > Some were simply slow. Others were not notified in advance (likely to > > > prevent it from being leaked). > > > [mathy] > > > > > Thanks for working on the patch at the time. I remember you were busy, > > > > > but still took the time to look at it once you had a chance. > > > > [stsp] > > > > Thank you for providing a patch I could use, and for testing my modified > > > > version. That was very helpful and I still very much appreciate it. > > > > > > > > If you ever find another problem, I'll be happy to collaborate again > > > > under > > > > full disclosure terms, as with TKIP/WPA1. If that's not your thing > > > > anymore, > > > > well, we'll have patches ready by time of public announcement in any > > > > case > > > > and will try to make the best of it. > > > [mathy] > > > This was a special case because it affected many implementations. I'm > > > more than happy to keep doing full-disclosure if there are any future > > > findings specific to OpenBSD! > > > > > > Cheers, > > > Mathy > > > > > > ----- End forwarded message ----- ----- End forwarded message -----
