Package: wpa / 2.3-1+deb8u5
Metadata
Package | Version | Patches format |
---|---|---|
wpa | 2.3-1+deb8u5 | 3.0 (quilt) |
Patch series
view the series filePatch | File delta | Description |
---|---|---|
01_use_pkg config_for_pcsc lite_module.patch | (download) |
wpa_supplicant/Makefile |
2 1 + 1 - 0 ! |
use pkg-config for libpcsclite linkage flags At least in debian, we can rely on pkg-config being available and returning more accurate ldflags. |
02_dbus_group_policy.patch | (download) |
wpa_supplicant/dbus/dbus-wpa_supplicant.conf |
8 8 + 0 - 0 ! |
debian does not use pam_console but uses group membership to control access to D-Bus. Activating both options in the conf file makes it work on Debian and Ubuntu. |
06_wpa_gui_menu_exec_path.patch | (download) |
wpa_supplicant/wpa_gui-qt4/wpa_gui.desktop |
2 1 + 1 - 0 ! |
debian specific patch to desktop meny entry, so that we may exec wpa_gui which being in /usr/sbin may not be in the PATH |
07_dbus_service_syslog.patch | (download) |
wpa_supplicant/dbus/fi.epitest.hostap.WPASupplicant.service.in |
2 1 + 1 - 0 ! |
tweak d-bus/systemd service activation configuration files: * log wpa_supplicant messages to syslog * activate control socket interface so that wpa_cli can be used by D-Bus activated wpa_supplicant daemon |
12_wpa_gui_knotify_support.patch | (download) |
wpa_supplicant/wpa_gui-qt4/wpagui.cpp |
18 16 + 2 - 0 ! |
use kde's knotify when running under kde |
wpa_gui_desktop_add keywords entry.patch | (download) |
wpa_supplicant/wpa_gui-qt4/wpa_gui.desktop |
1 1 + 0 - 0 ! |
--- |
wpa_supplicant MACsec fix build failure for IEEE8021.patch | (download) |
wpa_supplicant/wpa_supplicant.c |
2 1 + 1 - 0 ! |
[patch] wpa_supplicant/ macsec: fix build failure for IEEE8021X_EAPOL=n MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Building wpa_supplicant >= 2.2 fails on Debian/ kfreebsd with the following error message: cc -c -o wpa_supplicant.o -MMD -Wall -g -Os -fPIC -Isrc -Isrc/utils -DCONFIG_BACKEND_FILE -DCONFIG_DRIVER_BSD -DCONFIG_CTRL_IFACE -DCONFIG_CTRL_IFACE_UNIX wpa_supplicant.c wpa_supplicant.c: In function wpa_supplicant_initiate_eapol: wpa_supplicant.c:303:33: error: ssid undeclared (first use in this function) ieee802_1x_alloc_kay_sm(wpa_s, ssid); ^ wpa_supplicant.c:303:33: note: each undeclared identifier is reported only once for each function it appears in Move ieee802_1x_alloc_kay_sm(wpa_s, ssid) into the IEEE8021X_EAPOL ifdef, as the "ssid" is only conditionally defined for it. Signed-off-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> |
include ieee802_11_common.c in wpa_supplicant build .patch | (download) |
wpa_supplicant/Android.mk |
7 0 + 7 - 0 ! |
[patch] include ieee802_11_common.c in wpa_supplicant build unconditionally This is needed for number of items and it was possible to make a build configuration that did not include ieee802_11_common.c while still trying to use functions from there. While it would be possible to add NEED_80211_COMMON=y to all the cases where this file is needed, the extra complexity from this is not really justifiable anymore, so include the file unconditionally. Signed-off-by: Jouni Malinen <j@w1.fi> |
wpasupplicant_P2P Validate SSID element length before copying it C.patch | (download) |
src/p2p/p2p.c |
1 1 + 0 - 0 ! |
[patch] p2p: validate ssid element length before copying it (CVE-2015-1863) This fixes a possible memcpy overflow for P2P dev->oper_ssid in p2p_add_device(). The length provided by the peer device (0..255 bytes) was used without proper bounds checking and that could have resulted in arbitrary data of up to 223 bytes being written beyond the end of the dev->oper_ssid[] array (of which about 150 bytes would be beyond the heap allocation) when processing a corrupted management frame for P2P peer discovery purposes. This could result in corrupted state in heap, unexpected program behavior due to corrupted P2P peer device information, denial of service due to process crash, exposure of memory contents during GO Negotiation, and potentially arbitrary code execution. Thanks to Google security team for reporting this issue and smart hardware research group of Alibaba security team for discovering it. Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com> |
2015 2/0001 WPS Fix HTTP chunked transfer encoding parser.patch | (download) |
src/wps/httpread.c |
7 7 + 0 - 0 ! |
[patch] wps: fix http chunked transfer encoding parser strtoul() return value may end up overflowing the int h->chunk_size and resulting in a negative value to be stored as the chunk_size. This could result in the following memcpy operation using a very large length argument which would result in a buffer overflow and segmentation fault. This could have been used to cause a denial service by any device that has been authorized for network access (either wireless or wired). This would affect both the WPS UPnP functionality in a WPS AP (hostapd with upnp_iface parameter set in the configuration) and WPS ER (wpa_supplicant with WPS_ER_START control interface command used). Validate the parsed chunk length value to avoid this. In addition to rejecting negative values, we can also reject chunk size that would be larger than the maximum configured body length. Thanks to Kostya Kortchinsky of Google security team for discovering and reporting this issue. Signed-off-by: Jouni Malinen <j@w1.fi> |
2015 3/0001 AP WMM Fix integer underflow in WMM Action frame par.patch | (download) |
src/ap/wmm.c |
3 3 + 0 - 0 ! |
[patch] ap wmm: fix integer underflow in wmm action frame parser The length of the WMM Action frame was not properly validated and the length of the information elements (int left) could end up being negative. This would result in reading significantly past the stack buffer while parsing the IEs in ieee802_11_parse_elems() and while doing so, resulting in segmentation fault. This can result in an invalid frame being used for a denial of service attack (hostapd process killed) against an AP with a driver that uses hostapd for management frame processing (e.g., all mac80211-based drivers). Thanks to Kostya Kortchinsky of Google security team for discovering and reporting this issue. Signed-off-by: Jouni Malinen <j@w1.fi> |
2015 4/0001 EAP pwd peer Fix payload length validation for Commi.patch | (download) |
src/eap_peer/eap_pwd.c |
29 29 + 0 - 0 ! |
[patch 1/5] eap-pwd peer: fix payload length validation for commit and Confirm 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. Signed-off-by: Jouni Malinen <j@w1.fi> |
2015 4/0002 EAP pwd server Fix payload length validation for Com.patch | (download) |
src/eap_server/eap_server_pwd.c |
19 19 + 0 - 0 ! |
[patch 2/5] eap-pwd server: fix payload length validation for commit and Confirm 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. Signed-off-by: Jouni Malinen <j@w1.fi> |
2015 4/0003 EAP pwd peer Fix Total Length parsing for fragment r.patch | (download) |
src/eap_peer/eap_pwd.c |
12 12 + 0 - 0 ! |
[patch 3/5] eap-pwd peer: fix total-length parsing for fragment reassembly 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. Signed-off-by: Jouni Malinen <j@w1.fi> |
2015 4/0004 EAP pwd server Fix Total Length parsing for fragment.patch | (download) |
src/eap_server/eap_server_pwd.c |
10 10 + 0 - 0 ! |
[patch 4/5] eap-pwd server: fix total-length parsing for fragment reassembly 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. Signed-off-by: Jouni Malinen <j@w1.fi> |
2015 4/0005 EAP pwd peer Fix asymmetric fragmentation behavior.patch | (download) |
src/eap_peer/eap_pwd.c |
1 1 + 0 - 0 ! |
[patch 5/5] eap-pwd peer: fix asymmetric fragmentation behavior 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. Signed-off-by: Jouni Malinen <j@w1.fi> |
2015 5/0001 NFC Fix payload length validation in NDEF record par.patch | (download) |
src/wps/ndef.c |
5 4 + 1 - 0 ! |
[patch] nfc: fix payload length validation in ndef record parser It was possible for the 32-bit record->total_length value to end up wrapping around due to integer overflow if the longer form of payload length field is used and record->payload_length gets a value close to 2^32. This could result in ndef_parse_record() accepting a too large payload length value and the record type filter reading up to about 20 bytes beyond the end of the buffer and potentially killing the process. This could also result in an attempt to allocate close to 2^32 bytes of heap memory and if that were to succeed, a buffer read overflow of the same length which would most likely result in the process termination. In case of record->total_length ending up getting the value 0, there would be no buffer read overflow, but record parsing would result in an infinite loop in ndef_parse_records(). Any of these error cases could potentially be used for denial of service attacks over NFC by using a malformed NDEF record on an NFC Tag or sending them during NFC connection handover if the application providing the NDEF message to hostapd/wpa_supplicant did no validation of the received records. While such validation is likely done in the NFC stack that needs to parse the NFC messages before further processing, hostapd/wpa_supplicant better be prepared for any data being included here. Fix this by validating record->payload_length value in a way that detects integer overflow. (CID 122668) Signed-off-by: Jouni Malinen <j@w1.fi> |
CVE 2015 5310.patch | (download) |
wpa_supplicant/wnm_sta.c |
6 6 + 0 - 0 ! |
--- |
CVE 2015 5314.patch | (download) |
src/eap_server/eap_server_pwd.c |
6 3 + 3 - 0 ! |
--- |
CVE 2015 5315.patch | (download) |
src/eap_peer/eap_pwd.c |
7 3 + 4 - 0 ! |
--- |
CVE 2015 5316.patch | (download) |
src/eap_peer/eap_pwd.c |
3 2 + 1 - 0 ! |
--- |
2016 1/0001 WPS Reject a Credential with invalid passphrase.patch | (download) |
src/utils/common.c |
12 12 + 0 - 0 ! |
[patch 1/5] wps: reject a credential with invalid passphrase WPA/WPA2-Personal passphrase is not allowed to include control characters. Reject a Credential received from a WPS Registrar both as STA (Credential) and AP (AP Settings) if the credential is for WPAPSK or WPA2PSK authentication type and includes an invalid passphrase. This fixes an issue where hostapd or wpa_supplicant could have updated the configuration file PSK/passphrase parameter with arbitrary data from an external device (Registrar) that may not be fully trusted. Should such data include a newline character, the resulting configuration file could become invalid and fail to be parsed. Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com> |
2016 1/0002 Reject psk parameter set with invalid passphrase cha.patch | (download) |
wpa_supplicant/config.c |
6 6 + 0 - 0 ! |
[patch 2/5] reject psk parameter set with invalid passphrase character WPA/WPA2-Personal passphrase is not allowed to include control characters. Reject a passphrase configuration attempt if that passphrase includes an invalid passphrase. This fixes an issue where wpa_supplicant could have updated the configuration file psk parameter with arbitrary data from the control interface or D-Bus interface. While those interfaces are supposed to be accessible only for trusted users/applications, it may be possible that an untrusted user has access to a management software component that does not validate the passphrase value before passing it to wpa_supplicant. This could allow such an untrusted user to inject up to 63 characters of almost arbitrary data into the configuration file. Such configuration file could result in wpa_supplicant trying to load a library (e.g., opensc_engine_path, pkcs11_engine_path, pkcs11_module_path, load_dynamic_eap) from user controlled location when starting again. This would allow code from that library to be executed under the wpa_supplicant process privileges. Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com> |
2016 1/0003 Remove newlines from wpa_supplicant config network o.patch | (download) |
src/utils/common.c |
11 11 + 0 - 0 ! |
[patch 3/5] remove newlines from wpa_supplicant config network output Spurious newlines output while writing the config file can corrupt the wpa_supplicant configuration. Avoid writing these for the network block parameters. This is a generic filter that cover cases that may not have been explicitly addressed with a more specific commit to avoid control characters in the psk parameter. Signed-off-by: Paul Stewart <pstew@google.com> |
2016 1/0004 Reject SET_CRED commands with newline characters in .patch | (download) |
wpa_supplicant/config.c |
9 8 + 1 - 0 ! |
[patch 4/5] reject set_cred commands with newline characters in the string values Most of the cred block parameters are written as strings without filtering and if there is an embedded newline character in the value, unexpected configuration file data might be written. This fixes an issue where wpa_supplicant could have updated the configuration file cred parameter with arbitrary data from the control interface or D-Bus interface. While those interfaces are supposed to be accessible only for trusted users/applications, it may be possible that an untrusted user has access to a management software component that does not validate the credential value before passing it to wpa_supplicant. This could allow such an untrusted user to inject almost arbitrary data into the configuration file. Such configuration file could result in wpa_supplicant trying to load a library (e.g., opensc_engine_path, pkcs11_engine_path, pkcs11_module_path, load_dynamic_eap) from user controlled location when starting again. This would allow code from that library to be executed under the wpa_supplicant process privileges. Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com> |
2016 1/0005 Reject SET commands with newline characters in the s.patch | (download) |
wpa_supplicant/config.c |
6 6 + 0 - 0 ! |
[patch 5/5] reject set commands with newline characters in the string values Many of the global configuration parameters are written as strings without filtering and if there is an embedded newline character in the value, unexpected configuration file data might be written. This fixes an issue where wpa_supplicant could have updated the configuration file global parameter with arbitrary data from the control interface or D-Bus interface. While those interfaces are supposed to be accessible only for trusted users/applications, it may be possible that an untrusted user has access to a management software component that does not validate the value of a parameter before passing it to wpa_supplicant. This could allow such an untrusted user to inject almost arbitrary data into the configuration file. Such configuration file could result in wpa_supplicant trying to load a library (e.g., opensc_engine_path, pkcs11_engine_path, pkcs11_module_path, load_dynamic_eap) from user controlled location when starting again. This would allow code from that library to be executed under the wpa_supplicant process privileges. Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com> |
2017 1/0001 hostapd Avoid key reinstallation in FT handshake.patch | (download) |
src/ap/wpa_auth.c |
8 8 + 0 - 0 ! |
[patch 01/10] hostapd: avoid key reinstallation in ft handshake Do not reinstall TK to the driver during Reassociation Response frame processing if the first attempt of setting the TK succeeded. This avoids issues related to clearing the TX/RX PN that could result in reusing same PN values for transmitted frames (e.g., due to CCM nonce reuse and also hitting replay protection on the receiver) and accepting replayed frames on RX side. This issue was introduced by the commit 0e84c25434e6a1f283c7b4e62e483729085b78d2 ('FT: Fix PTK configuration in authenticator') which allowed wpa_ft_install_ptk() to be called multiple times with the same PTK. While the second configuration attempt is needed with some drivers, it must be done only if the first attempt failed. Signed-off-by: Mathy Vanhoef <Mathy.Vanhoef@cs.kuleuven.be> |
2017 1/0002 Prevent reinstallation of an already in use group ke.patch | (download) |
src/common/wpa_common.h |
11 11 + 0 - 0 ! |
[patch 02/10] prevent reinstallation of an already in-use group key Track the current GTK and IGTK that is in use and when receiving a (possibly retransmitted) Group Message 1 or WNM-Sleep Mode Response, do not install the given key if it is already in use. This prevents an attacker from trying to trick the client into resetting or lowering the sequence counter associated to the group key. Signed-off-by: Mathy Vanhoef <Mathy.Vanhoef@cs.kuleuven.be> |
2017 1/0003 Extend protection of GTK IGTK reinstallation of WNM .patch | (download) |
src/rsn_supp/wpa.c |
53 38 + 15 - 0 ! |
[patch 03/10] extend protection of gtk/igtk reinstallation of WNM-Sleep Mode cases This extends the protection to track last configured GTK/IGTK value separately from EAPOL-Key frames and WNM-Sleep Mode frames to cover a |
2017 1/0004 Fix PTK rekeying to generate a new ANonce.patch | (download) |
src/ap/wpa_auth.c |
24 21 + 3 - 0 ! |
[patch 04/10] fix ptk rekeying to generate a new anonce The Authenticator state machine path for PTK rekeying ended up bypassing the AUTHENTICATION2 state where a new ANonce is generated when going directly to the PTKSTART state since there is no need to try to determine the PMK again in such a case. This is far from ideal since the new PTK would depend on a new nonce only from the supplicant. Fix this by generating a new ANonce when moving to the PTKSTART state for the purpose of starting new 4-way handshake to rekey PTK. Signed-off-by: Jouni Malinen <j@w1.fi> |
2017 1/0005 TDLS Reject TPK TK reconfiguration.patch | (download) |
src/rsn_supp/tdls.c |
38 36 + 2 - 0 ! |
[patch 05/10] tdls: reject tpk-tk reconfiguration Do not try to reconfigure the same TPK-TK to the driver after it has been successfully configured. This is an explicit check to avoid issues related to resetting the TX/RX packet number. There was already a check for this for TPK M2 (retries of that message are ignored completely), so that behavior does not get modified. For TPK M3, the TPK-TK could have been reconfigured, but that was followed by immediate teardown of the link due to an issue in updating the STA entry. Furthermore, for TDLS with any real security (i.e., ignoring open/WEP), the TPK message exchange is protected on the AP path and simple replay attacks are not feasible. As an additional corner case, make sure the local nonce gets updated if the peer uses a very unlikely "random nonce" of all zeros. Signed-off-by: Jouni Malinen <j@w1.fi> |
2017 1/0007 WNM Ignore WNM Sleep Mode Response if WNM Sleep Mode.patch | (download) |
wpa_supplicant/ctrl_iface.c |
2 2 + 0 - 0 ! |
[patch 07/10] wnm: ignore wnm-sleep mode response if wnm-sleep mode has not been used The AP is not expected to send out a WNM-Sleep Mode Response frame without the STA trying to use WNM-Sleep Mode. Drop such unexpected responses to reduce unnecessary processing of the frame. Signed-off-by: Jouni Malinen <j@w1.fi> |
2017 1/0008 WNM Ignore WNM Sleep Mode Response without pending r.patch | (download) |
wpa_supplicant/wnm_sta.c |
4 3 + 1 - 0 ! |
[patch 08/10] wnm: ignore wnm-sleep mode response without pending request Commit 03ed0a52393710be6bdae657d1b36efa146520e5 ('WNM: Ignore WNM-Sleep Mode Response if WNM-Sleep Mode has not been used') started ignoring the response when no WNM-Sleep Mode Request had been used during the association. This can be made tighter by clearing the used flag when successfully processing a response. This adds an additional layer of protection against unexpected retransmissions of the response frame. Signed-off-by: Jouni Malinen <j@w1.fi> |
2017 1/0009 FT Do not allow multiple Reassociation Response fram.patch | (download) |
src/rsn_supp/wpa.c |
3 3 + 0 - 0 ! |
[patch 09/10] ft: do not allow multiple reassociation response frames The driver is expected to not report a second association event without the station having explicitly request a new association. As such, this case should not be reachable. However, since reconfiguring the same pairwise or group keys to the driver could result in nonce reuse issues, be extra careful here and do an additional state check to avoid this even if the local driver ends up somehow accepting an unexpected Reassociation Response frame. Signed-off-by: Jouni Malinen <j@w1.fi> |
2017 1/0010 TDLS Ignore incoming TDLS Setup Response retries.patch | (download) |
src/rsn_supp/tdls.c |
8 8 + 0 - 0 ! |
[patch 10/10] tdls: ignore incoming tdls setup response retries The Setup Response timer is relatively fast (500 ms) and there are instances where it fires on the responder side after the initiator has already sent out the TDLS Setup Confirm frame. Prevent the processing of this stale TDLS Setup Response frame on the initiator side. Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com> |