This merge proposal brings the wpa-supplicant snap up-to-date with respect to CVEs as compared to the latest Debian package in xenial-updates and xenial-security (2.4-0ubuntu6.5).
Note I skipped the patches from /2017-1/, as these were the Krack attack patches and they'd been merged directly from upstream instead of being pulled from 2.4-0ubuntu6.2. I did not verify that the krack fixes that
landed in this tree *exactly* matched the patches from 2.4-0ubuntu6.2 though. I tried to apply the first patch in the directory /debian/patches/2017-1/ and it failed to apply, so I assumed all of those patches had been applied.
Finally there are two commits in this merge proposal which apply on to EAP server, however as later patches included changes to the client and the server, it was just easier to leave these server-only patches in the sequence.
Unexpected fragment might result in data->inbuf not being allocated
before processing and that could have resulted in NULL pointer
dereference. Fix that by explicitly checking for data->inbuf to be
available before using it.
This adds an explicit check for 0 < x,y < prime based on RFC 5931,
2.8.5.2.2 requirement. The earlier checks might have covered this
implicitly, but it is safer to avoid any dependency on implicit checks
and specific crypto library behavior. (CVE-2019-9498 and CVE-2019-9499)
Furthermore, this moves the EAP-pwd element and scalar parsing and
validation steps into shared helper functions so that there is no need
to maintain two separate copies of this common functionality between the
server and peer implementations.
From 751288275f9a4e68263f63f4897d84e14fa31c61 Mon Sep 17 00:00:00 2001
From: Mathy Vanhoef <email address hidden>
Date: Sun, 31 Mar 2019 17:43:44 +0200
Subject: [PATCH 13/20] EAP-pwd client: Verify received scalar and element
When processing an EAP-pwd Commit frame, the server's scalar and element
(elliptic curve point) were not validated. This allowed an adversary to
bypass authentication, and act as a rogue Access Point (AP) if the
crypto implementation did not verify the validity of the EC point.
Fix this vulnerability by assuring the received scalar lies within the
valid range, and by checking that the received element is not the point
at infinity and lies on the elliptic curve being used. (CVE-2019-9499)
The vulnerability is only exploitable if OpenSSL version 1.0.2 or lower
is used, or if LibreSSL or wolfssl is used. Newer versions of OpenSSL
(and also BoringSSL) implicitly validate the elliptic curve point in
EC_POINT_set_affine_coordinates_GFp(), preventing the attack.
When processing an EAP-pwd Commit frame, verify that the peer's scalar
and elliptic curve element differ from the one sent by the server. This
prevents reflection attacks where the adversary reflects the scalar and
element sent by the server. (CVE-2019-9497)
The vulnerability allows an adversary to complete the EAP-pwd handshake
as any user. However, the adversary does not learn the negotiated
session key, meaning the subsequent 4-way handshake would fail. As a
result, this cannot be abused to bypass authentication unless EAP-pwd is
used in non-WLAN cases without any following key exchange that would
require the attacker to learn the MSK.
From 836effd864995447dd4a168f18bb7a32e1b7abd1 Mon Sep 17 00:00:00 2001
From: Mathy Vanhoef <email address hidden>
Date: Sun, 31 Mar 2019 17:13:06 +0200
Subject: [PATCH 11/20] EAP-pwd server: Verify received scalar and element
When processing an EAP-pwd Commit frame, the peer's scalar and element
(elliptic curve point) were not validated. This allowed an adversary to
bypass authentication, and impersonate any user if the crypto
implementation did not verify the validity of the EC point.
Fix this vulnerability by assuring the received scalar lies within the
valid range, and by checking that the received element is not the point
at infinity and lies on the elliptic curve being used. (CVE-2019-9498)
The vulnerability is only exploitable if OpenSSL version 1.0.2 or lower
is used, or if LibreSSL or wolfssl is used. Newer versions of OpenSSL
(and also BoringSSL) implicitly validate the elliptic curve point in
EC_POINT_set_affine_coordinates_GFp(), preventing the attack.
From c2cf18e0f03a3e14e63a0e51a9a30cf69b4fe724 Mon Sep 17 00:00:00 2001
From: Jouni Malinen <email address hidden>
Date: Tue, 26 Feb 2019 11:59:45 +0200
Subject: [PATCH 04/20] EAP-pwd: Use constant time and memory access for
finding the PWE
This algorithm could leak information to external observers in form of
timing differences or memory access patterns (cache use). While the
previous implementation had protection against the most visible timing
differences (looping 40 rounds and masking the legendre operation), it
did not protect against memory access patterns between the two possible
code paths in the masking operations. That might be sufficient to allow
an unprivileged process running on the same device to be able to
determine which path is being executed through a cache attack and based
on that, determine information about the used password.
Convert the PWE finding loop to use constant time functions and
identical memory access path without different branches for the QR/QNR
cases to minimize possible side-channel information similarly to the
changes done for SAE authentication. (CVE-2019-9495)
From 3c2bc90d84f0aa84e570e7d0cfca77d120aa74ba Mon Sep 17 00:00:00 2001
From: Jouni Malinen <email address hidden>
Date: Fri, 8 Mar 2019 00:24:12 +0200
Subject: [PATCH 03/20] OpenSSL: Use constant time selection for
crypto_bignum_legendre()
Get rid of the branches that depend on the result of the Legendre
operation. This is needed to avoid leaking information about different
temporary results in blinding mechanisms.
This is related to CVE-2019-9494 and CVE-2019-9495.
From de88e8686b3716e92046ce614b34e8c28a346213 Mon Sep 17 00:00:00 2001
From: Jouni Malinen <email address hidden>
Date: Wed, 27 Feb 2019 18:38:30 +0200
Subject: [PATCH 02/20] Add helper functions for constant time operations
These functions can be used to help implement constant time operations
for various cryptographic operations that must minimize externally
observable differences in processing (both in timing and also in
internal cache use, etc.).
This is related to CVE-2019-9494 and CVE-2019-9495.
From 2534d4dde2cdd6d3ddf28019f3ad2b9c331bd2eb Mon Sep 17 00:00:00 2001
From: Jouni Malinen <email address hidden>
Date: Tue, 26 Feb 2019 11:43:03 +0200
Subject: [PATCH 01/20] OpenSSL: Use constant time operations for private
bignums
This helps in reducing measurable timing differences in operations
involving private information. BoringSSL has removed BN_FLG_CONSTTIME
and expects specific constant time functions to be called instead, so a
bit different approach is needed depending on which library is used.
The main operation that needs protection against side channel attacks is
BN_mod_exp() that depends on private keys (the public key validation
step in crypto_dh_derive_secret() is an exception that can use the
faster version since it does not depend on private keys).
crypto_bignum_div() is currently used only in SAE FFC case with not
safe-prime groups and only with values that do not depend on private
keys, so it is not critical to protect it.
crypto_bignum_inverse() is currently used only in SAE FFC PWE
derivation. The additional protection here is targeting only OpenSSL.
BoringSSL may need conversion to using BN_mod_inverse_blinded().
This is related to CVE-2019-9494 and CVE-2019-9495.
