Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 554860 - <net-wireless/wpa_supplicant-2.5-r1: Incomplete WPS and P2P NFC NDEF record payload length validation
Summary: <net-wireless/wpa_supplicant-2.5-r1: Incomplete WPS and P2P NFC NDEF record p...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal minor (vote)
Assignee: Gentoo Security
URL: https://bugzilla.redhat.com/show_bug....
Whiteboard: B3 [glsa]
Keywords:
Depends on: 565224
Blocks:
  Show dependency tree
 
Reported: 2015-07-14 09:58 UTC by Agostino Sarubbo
Modified: 2016-06-27 10:36 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Agostino Sarubbo gentoo-dev 2015-07-14 09:58:48 UTC
From ${URL} :

A vulnerability was found in NDEF record parsing implementation in
hostapd and wpa_supplicant. This code is used when an NFC Tag or NFC
connection handover is used to trigger WPS or P2P operations. The parser
did include bounds checking for the NDEF record payload length, but due
to insufficient integer size, it was possible to trigger integer
overflow that would result in bypassing the validation step with some
malformed NDEF records.

This could result in denial of service due to hostapd/wpa_supplicant
process termination (buffer read overflow) or infinite loop. The issue
can be triggered only if the NFC stack on the device does not perform
required validation steps for received NFC messages before sending the
received message to hostapd/wpa_supplicant for processing.

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 NDEF records. While such validation is likely done in the NFC
stack that needs to parse the NFC messages before further processing,
hostapd/wpa_supplicant should have (re)confirmed NDEF message validity
properly.


Vulnerable versions/configurations

hostapd v0.7.0-v2.4 with CONFIG_WPS_NFC=y in the build configuration
(hostapd/.config) and NFC NDEF records passed to hostapd by the NFC
stack without validation.

wpa_supplicant v0.7.0-v2.4 with CONFIG_WPS_NFC=y in the build
configuration (wpa_supplicant/.config) and NFC NDEF records passed to
wpa_supplicant by the NFC stack without validation.

Note: No NFC stack implementation has yet been identified with
capability to pass the malformed NDEF record to
hostapd/wpa_supplicant. As such, it is not known whether this issue can
be triggered in practice.

Alternatively to an actual NFC operation trigger, the malformed NDEF
records could be provided by other applications running on the same
device if access to the hostapd/wpa_supplicant control interface is
available to untrusted components or users.

Upstream patch:
http://w1.fi/security/2015-5/0001-NFC-Fix-payload-length-validation-in-NDEF-record-par.patch


@maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
Comment 1 Bjarke Istrup Pedersen (RETIRED) gentoo-dev 2015-07-14 19:48:23 UTC
Fixed in 2.4-r4, please stabilize.
Comment 2 Aaron Bauman (RETIRED) gentoo-dev 2016-03-13 11:17:35 UTC
@arches, please stabilize:

=net-wireless/wpa_supplicant-2.4-r4

Added to existing GLSA request.
Comment 3 Bjarke Istrup Pedersen (RETIRED) gentoo-dev 2016-03-14 10:41:46 UTC
No, we already have a bug for stabilizing 2.5-r1 #565224 - please get the PPC people to stabilize that one instead.
Comment 4 Agostino Sarubbo gentoo-dev 2016-03-15 11:09:02 UTC
amd64 stable
Comment 5 Agostino Sarubbo gentoo-dev 2016-03-15 16:40:53 UTC
x86 stable
Comment 6 Bjarke Istrup Pedersen (RETIRED) gentoo-dev 2016-03-15 21:13:36 UTC
Removing 2.4-r4, since archs don't read the text (missing the ebuild would force them to read the text).

For future archs reading this, being confused - read my comment in #3 .
Also removing arm team, since 2.5-r1 is already marked as stable for arm.

Thanks.
Comment 7 Agostino Sarubbo gentoo-dev 2016-03-16 14:10:58 UTC
ppc stable
Comment 8 Agostino Sarubbo gentoo-dev 2016-03-17 11:35:12 UTC
ppc64 stable.

Maintainer(s), please cleanup.
Security, please vote.
Comment 9 Aaron Bauman (RETIRED) gentoo-dev 2016-03-17 13:12:19 UTC
Stabilization complete per bug 565224.

@maintainers, please cleanup.
Comment 10 Bjarke Istrup Pedersen (RETIRED) gentoo-dev 2016-03-17 21:06:38 UTC
Old version has been removed :-)
Comment 11 GLSAMaker/CVETool Bot gentoo-dev 2016-06-27 10:36:09 UTC
This issue was resolved and addressed in
 GLSA 201606-17 at https://security.gentoo.org/glsa/201606-17
by GLSA coordinator Aaron Bauman (b-man).