midnight
We discovered a denial-of-service vulnerability that allows an adversary to forcibly
disconnect the IWD client from a protected Wi-Fi network even when Wi-Fi Management Frame
Protection (MFP) is being used. The problem is that the reception of an unprotected and
invalid handshake message 1/4 will cause the client to disconnect even when MFP is used,
resulting in denial-of-service.
An example of an invalid handshake message 1/4 is one with the key install flag set.
Snippet from the logs:
src/netdev.c:netdev_unicast_notify() Unicast notification Control Port Frame(129)
src/netdev.c:netdev_control_port_frame_event()
src/eapol.c:eapol_handle_ptk_1_of_4() ifindex=19
4-Way handshake failed for ifindex: 19, reason: 1
src/netdev.c:netdev_mlme_notify() MLME notification Del Station(20)
src/netdev.c:netdev_link_notify() event 16 on ifindex 19
src/netdev.c:netdev_mlme_notify() MLME notification Deauthenticate(39)
src/netdev.c:netdev_deauthenticate_event()
src/netdev.c:netdev_link_notify() event 16 on ifindex 19
src/netdev.c:netdev_mlme_notify() MLME notification Disconnect(48)
src/netdev.c:netdev_disconnect_event()
We confirmed the attack against versions 1.24, 1.25, 1.26, 1.27. See the attachment for
our proof-of-concept code to reproduce the issue.
A potential solution is to discard the invalid handshake message instead of
disconnecting.
This issue was discovered by Domien Schepers (Northeastern University) and Mathy Vanhoef
(imec-DistriNet, KU Leuven).
4:50 a.m.
Hi Domien,
On 5/6/22 09:00, Domien Schepers wrote:
<snip>
We discovered a denial-of-service vulnerability that allows an
adversary to forcibly disconnect the IWD client from a protected Wi-Fi network even when
Wi-Fi Management Frame Protection (MFP) is being used. The problem is that the reception
Looks like kernel/driver is letting through an unencrypted EAPOL Data frame even
when we're already set up encryption keys. MFP won't really be of much help
here?
of an unprotected and invalid handshake message 1/4 will cause the client to
disconnect even when MFP is used, resulting in denial-of-service.
A potential solution is to discard the invalid handshake message
instead of disconnecting.
Yes, this particular symptom could be fixed in this way. 802.11-2020 does
explicitly state in section 12.7.2 that "EAPOL-Key frames containing invalid
field values shall be silently discarded." So I think I'll send a patch that
does that. But even then, we'd still be open to other forms of similar attacks.
The real fix is that we should not allow unencrypted EAPoL 1/4 packets (or EAP
for that matter) to be processed once the keys have been set (with the caveat
that there is special case of EAPoL 3/4 packets that are being retransmitted
during the initial handshake.) Unfortunately, 802.11 never explicitly requires
this that I can find.
In theory the EAPOL over NL80211 transport does provide us with a hint that a
packet was received encrypted or unencrypted. So we could try and drop any
unencrypted packets after the initial handshake is complete and the keys have
been set. But I'm not sure whether this hint can be always trusted? Also, the
legacy PAE raw socket transport also doesn't provide this information.
Did you bring this up with the kernel wireless maintainers by any chance?
Regards,
-Denis
132
days inactive
135
days old
1 comments
2 participants
participants (2)
-
Denis Kenzior -
Domien Schepers