Issue metadata
Sign in to add a comment
|
Security: Unauthenticated EAPOL-Key decryption in wpa_supplicant |
||||||||||||||||||||||
Issue descriptionPer https://w1.fi/security/2018-1/unauthenticated-eapol-key-decryption.txt TL;DR: Crypto attack against WPA2+TKIP due to lack of authentication before processing EAPOL-Key frames. Allows cleartext modification (causing DoS) and recovery of group encryption keys via many connection attempts. Setting medium severity since Chrome OS doesn't trust the network anyways. Might be a bigger deal for jetstream though - adding kevinhayes@ to CC to chime in. The patch provided by upstream applies cleanly against our wpa_supplicant-2.6 copy, I'll shortly upload a CL.
,
Aug 20
,
Aug 21
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/hostap/+/4d8309976cc7b8cd260ea25a9b14a9ba91dbfcbc commit 4d8309976cc7b8cd260ea25a9b14a9ba91dbfcbc Author: Mathy Vanhoef <Mathy.Vanhoef@cs.kuleuven.be> Date: Tue Aug 21 17:33:51 2018 WPA: Ignore unauthenticated encrypted EAPOL-Key data Ignore unauthenticated encrypted EAPOL-Key data in supplicant processing. When using WPA2, these are frames that have the Encrypted flag set, but not the MIC flag. When using WPA2, EAPOL-Key frames that had the Encrypted flag set but not the MIC flag, had their data field decrypted without first verifying the MIC. In case the data field was encrypted using RC4 (i.e., when negotiating TKIP as the pairwise cipher), this meant that unauthenticated but decrypted data would then be processed. An adversary could abuse this as a decryption oracle to recover sensitive information in the data field of EAPOL-Key messages (e.g., the group key). (CVE-2018-14526) BUG= chromium:875739 TEST=Builds and passes tests. Change-Id: Icbabe575aeb83b79155aa1ac4e679609cb834ed7 Signed-off-by: Mathy Vanhoef <Mathy.Vanhoef@cs.kuleuven.be> Reviewed-on: https://chromium-review.googlesource.com/1180885 Commit-Ready: Mattias Nissler <mnissler@chromium.org> Tested-by: Mattias Nissler <mnissler@chromium.org> Reviewed-by: Kirtika Ruchandani <kirtika@chromium.org> [modify] https://crrev.com/4d8309976cc7b8cd260ea25a9b14a9ba91dbfcbc/src/rsn_supp/wpa.c
,
Aug 21
Do we want to track updating to 2.7 on this bug as well?
,
Aug 22
,
Aug 22
Regarding Jetstream's use of WPA2 in the description... Jetstream uses WPA2-PSK with AES-CCMP cipher for current products. This cipher is not susceptible to the vuln. Good to know this is fixed in case we were to allow customers to degrade their security to TKIP.
,
Aug 22
Jetstream also forked wpa_s and stuck with 2.5 when we moved to 2.6, so we should be ok moving to 2.7 without them. The chrome os manifest will need to change, since Jetstream got the default "wpa_supplicant" path, and we got "wpa_supplicant-2.6". I am not sure how Eric managed a seamless transition b/w manifests.
,
Aug 24
Alright, I'm gonna mark this as fixed given that the fix has landed. As Kirtika points out, Jetstream is *not* fixed since they're not on 2.6. Kevin, holler if this is a problem for you. crbug.com/877621 tracks updating to wpa_supplicant to 2.7.
,
Aug 25
,
Aug 27
,
Dec 1
This bug has been closed for more than 14 weeks. Removing security view restrictions. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by mnissler@chromium.org
, Aug 20