This repository is a mirror of https://git.openwrt.org/openwrt/openwrt.git It is for reference only and is not active for check-ins. We will continue to accept Pull Requests here. They will be merged via staging trees then into openwrt.git.
Go to file
John Crispin 1961948585 wpa_supplicant: fix CVE-2018-14526
Unauthenticated EAPOL-Key decryption in wpa_supplicant

Published: August 8, 2018
Identifiers:
- CVE-2018-14526
Latest version available from: https://w1.fi/security/2018-1/

Vulnerability

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.

Vulnerable versions/configurations

All wpa_supplicant versions.

Acknowledgments

Thanks to Mathy Vanhoef of the imec-DistriNet research group of KU
Leuven for discovering and reporting this issue.

Possible mitigation steps

- Remove TKIP as an allowed pairwise cipher in RSN/WPA2 networks. This
can be done also on the AP side.

- Merge the following commits to wpa_supplicant and rebuild:

WPA: Ignore unauthenticated encrypted EAPOL-Key data

This patch is available from https://w1.fi/security/2018-1/

- Update to wpa_supplicant v2.7 or newer, once available

Signed-off-by: John Crispin <john@phrozen.org>
2018-08-10 15:48:21 +02:00
.github build: Update README & github help 2018-07-08 09:41:53 +01:00
config x86: add support to set GRUB menu entry title 2018-07-30 15:55:21 +02:00
include ath79: add support for Buffalo BHR-4GRV2 2018-08-09 18:44:57 +02:00
package wpa_supplicant: fix CVE-2018-14526 2018-08-10 15:48:21 +02:00
scripts scripts: time.pl: avoid hard Time::HiRes dependency 2018-08-05 12:24:01 +02:00
target ath79: add support for OCEDO Koala 2018-08-09 18:44:57 +02:00
toolchain toolchain/glibc: update to latest 2.26 commit 2018-08-07 14:28:48 +02:00
tools tools: findutils: fix compilation with glibc 2.28 2018-08-10 06:29:49 +02:00
.gitattributes add .gitattributes to prevent the git autocrlf option from messing with CRLF/LF in files 2012-05-08 13:30:49 +00:00
.gitignore .gitignore: add .project & .cproject for eclipse users 2018-01-17 11:07:17 +01:00
BSDmakefile add missing copyright header 2007-02-26 01:05:09 +00:00
Config.in merge: base: update base-files and basic config 2017-12-08 19:41:18 +01:00
feeds.conf.default feeds: switch git.lede-project.org URLs to git.openwrt.org 2018-01-16 16:59:22 +01:00
LICENSE finally move buildroot-ng to trunk 2016-03-20 17:29:15 +01:00
Makefile build: include package directory in sha256sums when running on buildbot 2018-06-27 18:54:09 +02:00
README build: README punctuation pendantry 2018-07-08 12:05:16 +01:00
rules.mk rules.mk: replace iremap when using GCC 8 2018-07-22 17:16:52 +02:00

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------

This is the buildsystem for the OpenWrt Linux distribution.

To build your own firmware you need a Linux, BSD or MacOSX system (case
sensitive filesystem required). Cygwin is unsupported because of the lack
of a case sensitive file system.

You need gcc, binutils, bzip2, flex, python, perl, make, find, grep, diff,
unzip, gawk, getopt, subversion, libz-dev and libc headers installed.

1. Run "./scripts/feeds update -a" to obtain all the latest package definitions
defined in feeds.conf / feeds.conf.default

2. Run "./scripts/feeds install -a" to install symlinks for all obtained
packages into package/feeds/

3. Run "make menuconfig" to select your preferred configuration for the
toolchain, target system & firmware packages.

4. Run "make" to build your firmware. This will download all sources, build
the cross-compile toolchain and then cross-compile the Linux kernel & all
chosen applications for your target system.

Sunshine!
	Your OpenWrt Community
	http://www.openwrt.org