diff options
| author | Jouni Malinen <j@w1.fi> | 2019-02-15 17:35:12 +0200 |
|---|---|---|
| committer | Andrej Shadura <andrewsh@debian.org> | 2019-02-19 19:14:56 +0100 |
| commit | 4e0745fcbe4acd9beb56e59de37accc1451ba916 (patch) | |
| tree | a45376c750a26102a77c23236bbf22d1d3cc781f | |
| parent | 8010f746f4fd209d910383413435458b6feef14a (diff) | |
Re: SV: [RFC] PMF: Allow Key ID in big endian format to workaround faulty APs
Message-ID: <20190215153512.GA16110@w1.fi>
: The following description was taken from the original email from
: Mikael Kanstrup <mikael.kanstrup@sony.com>, Message-ID:
: <20190214124653.24793-1-mikael.kanstrup@sony.com>
>> From: Daisuke Niwa <daisuke.niwa@sony.com>
>>
>> A few APs out on the market have got the byte order of IGTK key
>> index wrong making PMF enabled connections fail to connect. The faulty
>> APs request STAs to configure IGTK with key ID value 1024 or 1280.
>>
>> IEEE Std 802.11-2016 Chapter 9.4.2.55 "Management MIC element"
>> define the key ID to be either 4 or 5. All other key IDs are reserved.
>>
>> Out of spec values get rejected by lower cfg80211 layer set key
>> operation which in turn brings the connection down.
>>
>> Looking more closely into the values requested, 4 and 5 in 16-bit
>> network byte order/big endian byte order happens to correspond to
>> 1024 and 1280 respectively in wireless little endian byte order. As
>> connect attempts using out of spec values will anyway fail detect
>> and workaround the problem and leave the IGTK unconfigured
>> while allowing unicast PMF to be used.
: Bits of the original email by Jouni follow:
> > And maybe more importantly, that the particular IGTK is not a predictable
> > value where this type of workaround would result in a security vulnerability.
>
> Hard to tell just by looking at the IGTK received. But yeah good point.
One option here would be to modify wpa_supplicant_install_igtk() to
ignore wpa_sm_set_key() failure if keyidx is 0x0400 or 0x0500. In other
words, do not configure IGTK at all if the AP is using unexpected KeyID
and the local driver does not support that value instead of trying to
guess that the AP really meant keyidx 4 or 5. Would just need to confirm
that the local driver is rejecting any group-addressed robust management
frame if there is no key configured for the keyidx. The main benefit
here would be in the local driver not getting that IGTK value enabled if
there is a risk of it being predictable value that an attacker could use
to inject frames.
Gbp-Pq: Name PMF-Allow-Key-ID-in-BE-format.patch
| -rw-r--r-- | src/rsn_supp/wpa.c | 7 |
1 files changed, 6 insertions, 1 deletions
diff --git a/src/rsn_supp/wpa.c b/src/rsn_supp/wpa.c index 18f8c71..4214332 100644 --- a/src/rsn_supp/wpa.c +++ b/src/rsn_supp/wpa.c @@ -1050,7 +1050,12 @@ static int wpa_supplicant_install_igtk(struct wpa_sm *sm, igtk->igtk, len) < 0) { wpa_msg(sm->ctx->msg_ctx, MSG_WARNING, "WPA: Failed to configure IGTK to the driver"); - return -1; + /* Work around issues with APs that are know to use incorrect + * byte order for the KeyID field. Leave the IGTK unconfigured + * while allowing unicast PMF to be used. + */ + if (keyidx != 0x0400 && keyidx != 0x0500) + return -1; } if (wnm_sleep) { |