From: Stanislaw Gruszka <sgruszka@redhat.com>
To: mike@hellotwist.com
Cc: linux-wireless@vger.kernel.org, Kalle Valo <kvalo@codeaurora.org>
Subject: Re: [PATCH] rt2x00: Fix MMIC countermeasures.
Date: Wed, 2 Aug 2017 09:01:17 +0200 [thread overview]
Message-ID: <20170802070117.GA2790@redhat.com> (raw)
In-Reply-To: <CAKXXJEw72EYHJpdwoWhudmOmFF=w+u_JG3vrp=-TCfR3zhANZw@mail.gmail.com>
Hi
The patch was mangled by your email client, but I'm not sure if it is
correct anyway.
On Tue, Aug 01, 2017 at 06:43:33PM -0400, Michael Skeffington wrote:
> Mac80211 doesnt check MMIC failure until after falling through the
> check for whether the packet is decrypted. Therefore, this driver
> never causes MMIC countermeasures to be initiated.
The relevant mac80211 code look like this:
ieee80211_rx_result
ieee80211_rx_h_michael_mic_verify(struct ieee80211_rx_data *rx)
{
<snip>
/*
* No way to verify the MIC if the hardware stripped it or
* the IV with the key index. In this case we have solely rely
* on the driver to set RX_FLAG_MMIC_ERROR in the event of a
* MIC failure report.
*/
if (status->flag & (RX_FLAG_MMIC_STRIPPED | RX_FLAG_IV_STRIPPED)) {
if (status->flag & RX_FLAG_MMIC_ERROR)
goto mic_fail_no_key;
if (!(status->flag & RX_FLAG_IV_STRIPPED) && rx->key &&
rx->key->conf.cipher == WLAN_CIPHER_SUITE_TKIP)
goto update_iv;
return RX_CONTINUE;
}
/*
* Some hardware seems to generate Michael MIC failure reports; even
* though, the frame was not encrypted with TKIP and therefore has no
* MIC. Ignore the flag them to avoid triggering countermeasures.
*/
if (!rx->key || rx->key->conf.cipher != WLAN_CIPHER_SUITE_TKIP ||
!(status->flag & RX_FLAG_DECRYPTED))
return RX_CONTINUE;
if (rx->sdata->vif.type == NL80211_IFTYPE_AP && rx->key->conf.keyidx) {
/*
* APs with pairwise keys should never receive Michael MIC
* errors for non-zero keyidx because these are reserved for
* group keys and only the AP is sending real multicast
* frames in the BSS.
*/
return RX_DROP_UNUSABLE;
}
if (status->flag & RX_FLAG_MMIC_ERROR)
goto mic_fail;
<snip>
So we indeed check RX_FLAG_DECRYPTED and then RX_FLAG_MMIC_ERROR at some
point. However before that check, we also have:
if (status->flag & (RX_FLAG_MMIC_STRIPPED | RX_FLAG_IV_STRIPPED)) {
if (status->flag & RX_FLAG_MMIC_ERROR)
goto mic_fail_no_key;
and we always set RX_FLAG_MMIC_STRIPPED and RX_FLAG_IV_STRIPPED flags in
rt2800 driver. Hence I do not think patch fixes any problem.
Perhaps what should be done is change mic_fail_no_key to mic_fail label
in mac80211 to increase rx->key->u.tkip.mic_failures++ statistic.
Thanks
Stanislaw
next prev parent reply other threads:[~2017-08-02 7:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-01 22:43 [PATCH] rt2x00: Fix MMIC countermeasures Michael Skeffington
2017-08-02 7:01 ` Stanislaw Gruszka [this message]
2017-08-02 12:21 ` Johannes Berg
2017-08-02 13:43 ` Kalle Valo
2017-08-02 14:36 ` Michael Skeffington
2017-08-03 9:10 ` Stanislaw Gruszka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170802070117.GA2790@redhat.com \
--to=sgruszka@redhat.com \
--cc=kvalo@codeaurora.org \
--cc=linux-wireless@vger.kernel.org \
--cc=mike@hellotwist.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).