#
1.9 |
|
01-Mar-2021 |
christos |
Merge local changes from v2.7 -> v2.9 for wpa_supplicant and hostapd
|
Revision tags: netbsd-9-1-RELEASE phil-wifi-20200421 phil-wifi-20200411 is-mlppp-base phil-wifi-20200406 netbsd-9-0-RELEASE netbsd-9-0-RC2 netbsd-9-0-RC1 phil-wifi-20191119 netbsd-9-base phil-wifi-20190609
|
#
1.8 |
|
10-Apr-2019 |
christos |
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.
|
#
1.7 |
|
10-Apr-2019 |
christos |
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.
|
Revision tags: pgoyette-compat-20190127 pgoyette-compat-20190118
|
#
1.6 |
|
04-Jan-2019 |
christos |
merge conflicts.
|
Revision tags: netbsd-8-2-RELEASE netbsd-8-1-RELEASE netbsd-8-1-RC1 pgoyette-compat-1226 pgoyette-compat-1126 pgoyette-compat-1020 pgoyette-compat-0930 pgoyette-compat-0906 pgoyette-compat-0728 netbsd-8-0-RELEASE phil-wifi-base pgoyette-compat-0625 netbsd-8-0-RC2 pgoyette-compat-0521 pgoyette-compat-0502 pgoyette-compat-0422 netbsd-8-0-RC1 pgoyette-compat-0415 pgoyette-compat-0407 pgoyette-compat-0330 pgoyette-compat-0322 pgoyette-compat-0315 pgoyette-compat-base matt-nb8-mediatek-base perseant-stdc-iso10646-base netbsd-8-base prg-localcount2-base3 prg-localcount2-base2 prg-localcount2-base1 prg-localcount2-base pgoyette-localcount-20170426 bouyer-socketcan-base1 pgoyette-localcount-20170320 bouyer-socketcan-base pgoyette-localcount-20170107
|
#
1.5 |
|
21-Nov-2016 |
christos |
branches: 1.5.10; 1.5.12; 1.5.14; 1.5.18; 1.5.20; Merge conflicts.
|
Revision tags: pgoyette-localcount-20161104 localcount-20160914 pgoyette-localcount-20160806 pgoyette-localcount-20160726 pgoyette-localcount-base
|
#
1.4 |
|
09-May-2015 |
christos |
branches: 1.4.2; The L (Length) and M (More) flags needs to be cleared before deciding whether the locally generated response requires fragmentation. This fixes an issue where these flags from the server could have been invalid for the following message. In some cases, this could have resulted in triggering the wpabuf security check that would terminate the process due to invalid buffer allocation.
XXX: pullup-7
|
#
1.3 |
|
09-May-2015 |
christos |
The remaining number of bytes in the message could be smaller than the Total-Length field size, so the length needs to be explicitly checked prior to reading the field and decrementing the len variable. This could have resulted in the remaining length becoming negative and interpreted as a huge positive integer.
In addition, check that there is no already started fragment in progress before allocating a new buffer for reassembling fragments. This avoid a potential memory leak when processing invalid message.
XXX: pullup-7
|
#
1.2 |
|
09-May-2015 |
christos |
The length of the received Commit and Confirm message payloads was not checked before reading them. This could result in a buffer read overflow when processing an invalid message.
Fix this by verifying that the payload is of expected length before processing it. In addition, enforce correct state transition sequence to make sure there is no unexpected behavior if receiving a Commit/Confirm message before the previous exchanges have been completed.
Thanks to Kostya Kortchinsky of Google security team for discovering and reporting this issue.
XXX: pullup-7
|
#
1.1 |
|
07-Oct-2012 |
christos |
branches: 1.1.1; Initial revision
|
#
1.8 |
|
10-Apr-2019 |
christos |
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.
|
#
1.7 |
|
10-Apr-2019 |
christos |
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.
|
Revision tags: pgoyette-compat-20190127 pgoyette-compat-20190118
|
#
1.6 |
|
04-Jan-2019 |
christos |
merge conflicts.
|
Revision tags: pgoyette-compat-1226 pgoyette-compat-1126 pgoyette-compat-1020 pgoyette-compat-0930 pgoyette-compat-0906 pgoyette-compat-0728 netbsd-8-0-RELEASE phil-wifi-base pgoyette-compat-0625 netbsd-8-0-RC2 pgoyette-compat-0521 pgoyette-compat-0502 pgoyette-compat-0422 netbsd-8-0-RC1 pgoyette-compat-0415 pgoyette-compat-0407 pgoyette-compat-0330 pgoyette-compat-0322 pgoyette-compat-0315 pgoyette-compat-base matt-nb8-mediatek-base perseant-stdc-iso10646-base netbsd-8-base prg-localcount2-base3 prg-localcount2-base2 prg-localcount2-base1 prg-localcount2-base pgoyette-localcount-20170426 bouyer-socketcan-base1 pgoyette-localcount-20170320 bouyer-socketcan-base pgoyette-localcount-20170107
|
#
1.5 |
|
21-Nov-2016 |
christos |
branches: 1.5.10; 1.5.12; 1.5.14; 1.5.18; Merge conflicts.
|
Revision tags: pgoyette-localcount-20161104 localcount-20160914 pgoyette-localcount-20160806 pgoyette-localcount-20160726 pgoyette-localcount-base
|
#
1.4 |
|
09-May-2015 |
christos |
branches: 1.4.2; The L (Length) and M (More) flags needs to be cleared before deciding whether the locally generated response requires fragmentation. This fixes an issue where these flags from the server could have been invalid for the following message. In some cases, this could have resulted in triggering the wpabuf security check that would terminate the process due to invalid buffer allocation.
XXX: pullup-7
|
#
1.3 |
|
09-May-2015 |
christos |
The remaining number of bytes in the message could be smaller than the Total-Length field size, so the length needs to be explicitly checked prior to reading the field and decrementing the len variable. This could have resulted in the remaining length becoming negative and interpreted as a huge positive integer.
In addition, check that there is no already started fragment in progress before allocating a new buffer for reassembling fragments. This avoid a potential memory leak when processing invalid message.
XXX: pullup-7
|
#
1.2 |
|
09-May-2015 |
christos |
The length of the received Commit and Confirm message payloads was not checked before reading them. This could result in a buffer read overflow when processing an invalid message.
Fix this by verifying that the payload is of expected length before processing it. In addition, enforce correct state transition sequence to make sure there is no unexpected behavior if receiving a Commit/Confirm message before the previous exchanges have been completed.
Thanks to Kostya Kortchinsky of Google security team for discovering and reporting this issue.
XXX: pullup-7
|
#
1.1 |
|
07-Oct-2012 |
christos |
branches: 1.1.1; Initial revision
|
#
1.5 |
|
21-Nov-2016 |
christos |
Merge conflicts.
|
Revision tags: pgoyette-localcount-20161104 localcount-20160914 pgoyette-localcount-20160806 pgoyette-localcount-20160726 pgoyette-localcount-base
|
#
1.4 |
|
09-May-2015 |
christos |
The L (Length) and M (More) flags needs to be cleared before deciding whether the locally generated response requires fragmentation. This fixes an issue where these flags from the server could have been invalid for the following message. In some cases, this could have resulted in triggering the wpabuf security check that would terminate the process due to invalid buffer allocation.
XXX: pullup-7
|
#
1.3 |
|
09-May-2015 |
christos |
The remaining number of bytes in the message could be smaller than the Total-Length field size, so the length needs to be explicitly checked prior to reading the field and decrementing the len variable. This could have resulted in the remaining length becoming negative and interpreted as a huge positive integer.
In addition, check that there is no already started fragment in progress before allocating a new buffer for reassembling fragments. This avoid a potential memory leak when processing invalid message.
XXX: pullup-7
|
#
1.2 |
|
09-May-2015 |
christos |
The length of the received Commit and Confirm message payloads was not checked before reading them. This could result in a buffer read overflow when processing an invalid message.
Fix this by verifying that the payload is of expected length before processing it. In addition, enforce correct state transition sequence to make sure there is no unexpected behavior if receiving a Commit/Confirm message before the previous exchanges have been completed.
Thanks to Kostya Kortchinsky of Google security team for discovering and reporting this issue.
XXX: pullup-7
|
#
1.1 |
|
07-Oct-2012 |
christos |
branches: 1.1.1; Initial revision
|