All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: linux-wireless@vger.kernel.org
Cc: Johannes Berg <johannes.berg@intel.com>,
	stable@vger.kernel.org, Jouni Malinen <jouni@codeaurora.org>
Subject: [PATCH 09/18] mac80211: do not accept/forward invalid EAPOL frames
Date: Tue, 11 May 2021 20:02:50 +0200	[thread overview]
Message-ID: <20210511200110.cb327ed0cabe.Ib7dcffa2a31f0913d660de65ba3c8aca75b1d10f@changeid> (raw)
In-Reply-To: <20210511180259.159598-1-johannes@sipsolutions.net>

From: Johannes Berg <johannes.berg@intel.com>

EAPOL frames are used for authentication and key management between the
AP and each individual STA associated in the BSS. Those frames are not
supposed to be sent by one associated STA to another associated STA
(either unicast for broadcast/multicast).

Similarly, in 802.11 they're supposed to be sent to the authenticator
(AP) address.

Since it is possible for unexpected EAPOL frames to result in misbehavior
in supplicant implementations, it is better for the AP to not allow such
cases to be forwarded to other clients either directly, or indirectly if
the AP interface is part of a bridge.

Accept EAPOL (control port) frames only if they're transmitted to the
own address, or, due to interoperability concerns, to the PAE group
address.

Disable forwarding of EAPOL (or well, the configured control port
protocol) frames back to wireless medium in all cases. Previously, these
frames were accepted from fully authenticated and authorized stations
and also from unauthenticated stations for one of the cases.

Additionally, to avoid forwarding by the bridge, rewrite the PAE group
address case to the local MAC address.

Cc: stable@vger.kernel.org
Co-developed-by: Jouni Malinen <jouni@codeaurora.org>
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
 net/mac80211/rx.c | 33 +++++++++++++++++++++++++++------
 1 file changed, 27 insertions(+), 6 deletions(-)

diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 4454ec47283f..22a925899a9e 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2531,13 +2531,13 @@ static bool ieee80211_frame_allowed(struct ieee80211_rx_data *rx, __le16 fc)
 	struct ethhdr *ehdr = (struct ethhdr *) rx->skb->data;
 
 	/*
-	 * Allow EAPOL frames to us/the PAE group address regardless
-	 * of whether the frame was encrypted or not.
+	 * Allow EAPOL frames to us/the PAE group address regardless of
+	 * whether the frame was encrypted or not, and always disallow
+	 * all other destination addresses for them.
 	 */
-	if (ehdr->h_proto == rx->sdata->control_port_protocol &&
-	    (ether_addr_equal(ehdr->h_dest, rx->sdata->vif.addr) ||
-	     ether_addr_equal(ehdr->h_dest, pae_group_addr)))
-		return true;
+	if (unlikely(ehdr->h_proto == rx->sdata->control_port_protocol))
+		return ether_addr_equal(ehdr->h_dest, rx->sdata->vif.addr) ||
+		       ether_addr_equal(ehdr->h_dest, pae_group_addr);
 
 	if (ieee80211_802_1x_port_control(rx) ||
 	    ieee80211_drop_unencrypted(rx, fc))
@@ -2562,8 +2562,28 @@ static void ieee80211_deliver_skb_to_local_stack(struct sk_buff *skb,
 		cfg80211_rx_control_port(dev, skb, noencrypt);
 		dev_kfree_skb(skb);
 	} else {
+		struct ethhdr *ehdr = (void *)skb_mac_header(skb);
+
 		memset(skb->cb, 0, sizeof(skb->cb));
 
+		/*
+		 * 802.1X over 802.11 requires that the authenticator address
+		 * be used for EAPOL frames. However, 802.1X allows the use of
+		 * the PAE group address instead. If the interface is part of
+		 * a bridge and we pass the frame with the PAE group address,
+		 * then the bridge will forward it to the network (even if the
+		 * client was not associated yet), which isn't supposed to
+		 * happen.
+		 * To avoid that, rewrite the destination address to our own
+		 * address, so that the authenticator (e.g. hostapd) will see
+		 * the frame, but bridge won't forward it anywhere else. Note
+		 * that due to earlier filtering, the only other address can
+		 * be the PAE group address.
+		 */
+		if (unlikely(skb->protocol == sdata->control_port_protocol &&
+			     !ether_addr_equal(ehdr->h_dest, sdata->vif.addr)))
+			ether_addr_copy(ehdr->h_dest, sdata->vif.addr);
+
 		/* deliver to local stack */
 		if (rx->list)
 			list_add_tail(&skb->list, rx->list);
@@ -2603,6 +2623,7 @@ ieee80211_deliver_skb(struct ieee80211_rx_data *rx)
 	if ((sdata->vif.type == NL80211_IFTYPE_AP ||
 	     sdata->vif.type == NL80211_IFTYPE_AP_VLAN) &&
 	    !(sdata->flags & IEEE80211_SDATA_DONT_BRIDGE_PACKETS) &&
+	    ehdr->h_proto != rx->sdata->control_port_protocol &&
 	    (sdata->vif.type != NL80211_IFTYPE_AP_VLAN || !sdata->u.vlan.sta)) {
 		if (is_multicast_ether_addr(ehdr->h_dest) &&
 		    ieee80211_vif_get_num_mcast_if(sdata) != 0) {
-- 
2.30.2


  parent reply	other threads:[~2021-05-11 18:03 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-11 18:02 [PATCH 00/18] mac80211/driver security fixes Johannes Berg
2021-05-11 18:02 ` [PATCH 01/18] mac80211: assure all fragments are encrypted Johannes Berg
2021-05-11 18:02 ` [PATCH 02/18] mac80211: prevent mixed key and fragment cache attacks Johannes Berg
2021-05-11 18:02 ` [PATCH 03/18] mac80211: properly handle A-MSDUs that start with an RFC 1042 header Johannes Berg
2021-05-11 18:02 ` [PATCH 04/18] cfg80211: mitigate A-MSDU aggregation attacks Johannes Berg
2021-05-11 18:02 ` [PATCH 05/18] mac80211: drop A-MSDUs on old ciphers Johannes Berg
2021-05-11 18:02 ` [PATCH 06/18] mac80211: add fragment cache to sta_info Johannes Berg
2021-05-11 18:02 ` [PATCH 07/18] mac80211: check defrag PN against current frame Johannes Berg
2021-05-11 18:02 ` [PATCH 08/18] mac80211: prevent attacks on TKIP/WEP as well Johannes Berg
2021-05-11 18:02 ` Johannes Berg [this message]
2021-05-11 18:02 ` [PATCH 10/18] mac80211: extend protection against mixed key and fragment cache attacks Johannes Berg
2021-05-11 18:02 ` [PATCH 11/18] ath10k: add CCMP PN replay protection for fragmented frames for PCIe Johannes Berg
2021-05-14 22:23   ` Abhishek Kumar
2021-05-11 18:02 ` [PATCH 12/18] ath10k: drop fragments with multicast DA " Johannes Berg
2021-05-11 18:02 ` [PATCH 13/18] ath10k: drop fragments with multicast DA for SDIO Johannes Berg
2021-05-11 18:02 ` [PATCH 14/18] ath10k: drop MPDU which has discard flag set by firmware " Johannes Berg
2021-05-12 18:35   ` Brian Norris
2021-05-13 17:18     ` Jeff Johnson
2021-05-11 18:02 ` [PATCH 15/18] ath10k: Fix TKIP Michael MIC verification for PCIe Johannes Berg
2021-05-11 18:02 ` [PATCH 16/18] ath10k: Validate first subframe of A-MSDU before processing the list Johannes Berg
2021-05-11 18:02 ` [PATCH 17/18] ath11k: Clear the fragment cache during key install Johannes Berg
2021-05-11 18:02 ` [PATCH 18/18] ath11k: Drop multicast fragments Johannes Berg
2021-05-17 18:54 ` [PATCH 00/18] mac80211/driver security fixes Ben Greear

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=20210511200110.cb327ed0cabe.Ib7dcffa2a31f0913d660de65ba3c8aca75b1d10f@changeid \
    --to=johannes@sipsolutions.net \
    --cc=johannes.berg@intel.com \
    --cc=jouni@codeaurora.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.