CVE-2017-13077 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-13077): ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. CVE-2017-13078 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-13078): ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. CVE-2017-13079 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-13079): ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. CVE-2017-13080 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-13080): ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. CVE-2017-13081 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-13081): ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. CVE-2017-13082 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-13082): ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. CVE-2017-13086 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-13086): ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. CVE-2017-13087 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-13087): ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. CVE-2017-13088 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-13088): ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided.
A vulnerability was found in how a number of implementations can be triggered to reconfigure WPA/WPA2/RSN keys (TK, GTK, or IGTK) by replaying a specific frame that is used to manage the keys. Such reinstallation of the encryption key can result in two different types of vulnerabilities: disabling replay protection and significantly reducing the security of encryption to the point of allowing frames to be decrypted or some parts of the keys to be determined by an attacker depending on which cipher is used. This document focuses on the cases that apply to systems using hostapd (AP) or wpa_supplicant (station), but it should be noted that the generic vulnerability itself is applicable to other implementations and may have different impact in other cases. This vulnerability can in theory apply to any case where a TK (the pairwise/unicast encryption key used with TKIP, CCMP, GCMP), a GTK (group/multicast encryption key), or an IGTK (group management frame integrity protection key) is configured by the Authentication/Supplicant component to the WLAN driver/firmware taking care of the TX/RX path and encryption/decryption of frames. If the same key is configured multiple times, it is likely that the transmit and receive packet numbers (PN, IPN, RSC/TSC, etc.) are cleared to a smaller value (zero in case of pairwise keys, zero or at least a smaller value than the last used value in case of group keys). When this happens with the same key, this breaks replay protection on RX side and can result in reuse of packet numbers on TX side. The former may allow replaying of previously delivered packets (without the attacker being able to decrypt them or modify their contents) while the latter may result in more severe issues on the TX side due to resulting CCM nonce replay and related issues with GCMP and TKIP. The TX side issue may make it significantly easier for the attacker to decrypt frames and determine some parts of the keys (e.g., a Michael MIC key in case of TKIP).
Many articles about this issue point to this list of affected vendors: http://www.kb.cert.org/vuls/byvendor?searchview&Query=FIELD+Reference=228519&SearchOrder=4 Maybe somebody could officially update the Gentoo page (http://www.kb.cert.org/vuls/id/CHEU-AQNN3Z)?
*** Bug 634420 has been marked as a duplicate of this bug. ***
