From owner-svn-ports-head@freebsd.org Tue Aug 14 20:21:54 2018 Return-Path: Delivered-To: svn-ports-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0EF61105BC6B; Tue, 14 Aug 2018 20:21:54 +0000 (UTC) (envelope-from cy@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B95FD86870; Tue, 14 Aug 2018 20:21:53 +0000 (UTC) (envelope-from cy@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 9A971205C0; Tue, 14 Aug 2018 20:21:53 +0000 (UTC) (envelope-from cy@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w7EKLrCr011179; Tue, 14 Aug 2018 20:21:53 GMT (envelope-from cy@FreeBSD.org) Received: (from cy@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w7EKLrJr011178; Tue, 14 Aug 2018 20:21:53 GMT (envelope-from cy@FreeBSD.org) Message-Id: <201808142021.w7EKLrJr011178@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: cy set sender to cy@FreeBSD.org using -f From: Cy Schubert Date: Tue, 14 Aug 2018 20:21:53 +0000 (UTC) To: ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: svn commit: r477201 - head/security/vuxml X-SVN-Group: ports-head X-SVN-Commit-Author: cy X-SVN-Commit-Paths: head/security/vuxml X-SVN-Commit-Revision: 477201 X-SVN-Commit-Repository: ports MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-ports-head@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: SVN commit messages for the ports tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2018 20:21:54 -0000 Author: cy Date: Tue Aug 14 20:21:52 2018 New Revision: 477201 URL: https://svnweb.freebsd.org/changeset/ports/477201 Log: Document WPA unauthenticated encrypted EAPOL-Key data vunlerability. Security: CVE-2018-14526 Modified: head/security/vuxml/vuln.xml Modified: head/security/vuxml/vuln.xml ============================================================================== --- head/security/vuxml/vuln.xml Tue Aug 14 19:43:40 2018 (r477200) +++ head/security/vuxml/vuln.xml Tue Aug 14 20:21:52 2018 (r477201) @@ -58,6 +58,76 @@ Notes: * Do not forget port variants (linux-f10-libxml2, libxml2, etc.) --> + + wpa_supplicant -- unauthenticated encrypted EAPOL-Key data + + + wpa_supplicant + 2.6_2 + + + FreeBSD + 10.4_10 + 11.2_1 + + + + +

SO-AND-SO reports:

+
A vulnerability was found in how wpa_supplicant processes + EAPOL-Key frames. It is possible for an attacker to modify + the frame in a way that makes wpa_supplicant decrypt the Key + Data field without requiring a valid MIC value in the frame, + i.e., without the frame being authenticated. This has a + potential issue in the case where WPA2/RSN style of EAPOL-Key + construction is used with TKIP negotiated as the pairwise + cipher. It should be noted that WPA2 is not supposed to be + used with TKIP as the pairwise cipher. Instead, CCMP is + expected to be used and with that pairwise cipher, this + vulnerability is not applicable in practice.
+
When TKIP is negotiated as the pairwise cipher, the EAPOL-Key + Key Data field is encrypted using RC4. This vulnerability + allows unauthenticated EAPOL-Key frames to be processed and + due to the RC4 design, this makes it possible for an attacker + to modify the plaintext version of the Key Data field with + bitwise XOR operations without knowing the contents. This can + be used to cause a denial of service attack by modifying + GTK/IGTK on the station (without the attacker learning any of + the keys) which would prevent the station from accepting + received group-addressed frames. Furthermore, this might be + abused by making wpa_supplicant act as a decryption oracle to + try to recover some of the Key Data payload (GTK/IGTK) to get + knowledge of the group encryption keys.
+
Full recovery of the group encryption keys requires multiple + attempts (128 connection attempts per octet) and each attempt + results in disconnection due to a failure to complete the 4-way + handshake. These failures can result in the AP/network getting + disabled temporarily or even permanently (requiring user action + to re-enable) which may make it impractical to perform the + attack to recover the keys before the AP has already changes + the group keys. By default, wpa_supplicant is enforcing at + minimum a ten second wait time between each failed connection + attempt, i.e., over 20 minutes waiting to recover each octet + while hostapd AP implementation uses 10 minute default for GTK + rekeying when using TKIP. With such timing behavior, practical + attack would need large number of impacted stations to be + trying to connect to the same AP to be able to recover + sufficient information from the GTK to be able to determine + the key before it gets changed.
+

+ + + + https://w1.fi/security/2018-1/unauthenticated-eapol-key-decryption.txt + CVE-2018-14526 + + + 2018-08-08 + 2018-08-14 + + + Flash Player -- multiple vulnerabilities