Bugzilla Bug 81993

A possible buffer overflow was discovered in wpa_supplicant-0.2.6, which is
currently marked stable on x86, today:

From: Jouni Malinen <jkmaline@cc.hut.fi>
To: hostap@shmoo.com
Subject: wpa_supplicant - new stable releases v0.3.8 and v0.2.7
Date: Sun, 13 Feb 2005 18:35:31 -0800  (Mon, 03:35 CET)

New versions of wpa_supplicant stable branches were just released and
are now available from http://hostap.epitest.fi/

This release is a bug fix release for all current stable branches. A
missing validation of received EAPOL-Key frames was found during code
review. This omission makes it possible to construct a packet that
will cause wpa_supplicant to crash with segmentation fault due to
buffer overflow when reading the invalid EAPOL-Key packet data.

This omission of required validation step happened during addition of
WPA2 support and is thus present in all released versions of
wpa_supplicant except for the first v0.2.0 release that did not yet
have WPA2 support. If WPA2 is enabled ('proto' configuration variable
includes WPA2 or RSN, or is commented out in configuration), an
unauthenticated EAPOL-Key frame (message 1 of 4-Way Handshake) can
trigger this failure. If WPA2 is not enabled, only authenticated
frames (message 3 of 4-Way Handshake) trigger this failure, i.e., AP
must be able to determine the correct PMK and PTK to send such a frame.

All users of wpa_supplicant are recommended to update to the new
versions, either v0.3.8 or v0.2.7. Alternatively, the attached patch
can be used to add the missing validation for EAPOL-Key frames. This
patch should apply to all versions starting from v0.2.2 (with some
offset differences). This change is also included in the current
development snapshot.


wpa_supplicant:
* fixed EAPOL-Key validation to drop packets with invalid Key Data
  Length; such frames could have crashed wpa_supplicant due to buffer
  overflow

I have added net-wireless/wpa_supplicant-0.2.7 to portage and marked it stable
on x86. I've also pulled all vulnerable versions of the package.

Thx Henrik.

This one is ready for GLSA, Security please vote (or complain about B rating).

I vote YES, this can lead to denial of service in pure sense.

GLSA 200502-22

thanks everyone