d/freebsd-dev
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

net80211: fail for unicast traffic without unicast key

Browse Source 
Falling back to the multicast key may cause unicast traffic to leak.
Instead fail when no key is found.

For more information see the 'Framing Frames: Bypassing Wi-Fi Encryption
by Manipulating Transmit Queues' paper.

[ I updated the commit message to reference the paper and the code
comment to record historic behaviour as discussed in private email. ]

Security:	CVE-2022-47522
This commit is contained in:
domienschepers 2022-11-10 00:00:00 +00:00 committed by Bjoern A. Zeeb
parent 461ccb55d5
commit 61605e0ae5
1 changed files with 11 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
sys/net80211/ieee80211_crypto.c
View File

@ -560,13 +560,17 @@ ieee80211_crypto_get_txkey(struct ieee80211_node *ni, struct mbuf *m)
/*
* Multicast traffic always uses the multicast key.
* Otherwise if a unicast key is set we use that and
* it is always key index 0. When no unicast key is
* set we fall back to the default transmit key.
*
* Historically we would fall back to the default
* transmit key if there was no unicast key. This
* behaviour was documented up to IEEE Std 802.11-2016,
* 12.9.2.2 Per-MSDU/Per-A-MSDU Tx pseudocode, in the
* 'else' case but is no longer in later versions of
* the standard. Additionally falling back to the
* group key for unicast was a security risk.
*/
wh = mtod(m, struct ieee80211_frame *);
if (IEEE80211_IS_MULTICAST(wh->i_addr1) ||
IEEE80211_KEY_UNDEFINED(&ni->ni_ucastkey)) {
if (IEEE80211_IS_MULTICAST(wh->i_addr1)) {
if (vap->iv_def_txkey == IEEE80211_KEYIX_NONE) {
IEEE80211_NOTE_MAC(vap, IEEE80211_MSG_CRYPTO,
wh->i_addr1,
@ -578,6 +582,8 @@ ieee80211_crypto_get_txkey(struct ieee80211_node *ni, struct mbuf *m)
return &vap->iv_nw_keys[vap->iv_def_txkey];
}
if (IEEE80211_KEY_UNDEFINED(&ni->ni_ucastkey))
return NULL;
return &ni->ni_ucastkey;
}