Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 27 Oct 2011 15:02:12 +0200
From:      Bernhard Schmidt <bschmidt@freebsd.org>
To:        Adrian Chadd <adrian@freebsd.org>
Cc:        freebsd-wireless@freebsd.org
Subject:   Re: [patch] net80211: reject STA frames not destined to the current STA VAP MAC address
Message-ID:  <201110271502.12654.bschmidt@freebsd.org>
In-Reply-To: <CAJ-Vmo=jYt4zddQyKw85Gxi-TFB8ETjQYFjQTTEjuWvdXmC97Q@mail.gmail.com>
References:  <CAJ-Vmo=CZ-c0QN_qoXQa4gyo5MyxL=DUzy6nXkX27HEDr17iqA@mail.gmail.com> <201110262123.55543.bschmidt@freebsd.org> <CAJ-Vmo=jYt4zddQyKw85Gxi-TFB8ETjQYFjQTTEjuWvdXmC97Q@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
--Boundary-00=_UZVqOCBfTsaSL2w
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

On Thursday 27 October 2011 04:45:24 Adrian Chadd wrote:
> On 27 October 2011 03:23, Bernhard Schmidt <bschmidt@freebsd.org> wrote:
> 
> > I doubt this is necessary. Receiving frames with DST != vap->iv_myaddr
> > works just fine with iwn(4) and WPA.
> 
> But it does, and it does mess up the crypto IV tracking. I added
> debugging to net80211 to track what happens:
> 
> * a frame that doesn't match the station destination address comes in;
> * it doesn't have a crypto key, and it doesn't match any mac address;
> * so it's sent to all VAPs via ieee80211_input_all();
> * somehow it ends up updating the crypto state for the BSS, setting
> the IV to what was in the destination address, as well as the sequence
> number;
> * subsequent frames (to the real station destination) are now dropped
> because the replay attack code and/or the sequence number tracking
> code drops the frame.
> 
> I traced it down to the driver handing off the net80211 STA code a
> frame whose destination is not the STA and is an AP->STA frame.

Allright, the important part here seems to be that the seqnos have to
be in a certain order to even remotely trigger an issue. Otherwise
the frames are just discarded as either out of order or because of
replay detection. I'd still add its own counter though, how about
that?

-- 
Bernhard

--Boundary-00=_UZVqOCBfTsaSL2w
Content-Type: text/x-patch; charset="ISO-8859-1"; name="net80211_wrongdst.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="net80211_wrongdst.diff"

Index: sys/net80211/ieee80211_sta.c
===================================================================
--- sys/net80211/ieee80211_sta.c	(revision 226808)
+++ sys/net80211/ieee80211_sta.c	(working copy)
@@ -582,6 +582,12 @@ sta_input(struct ieee80211_node *ni, struct mbuf *
 			vap->iv_stats.is_rx_wrongbss++;
 			goto out;
 		}
+		if (!IEEE80211_ADDR_EQ(vap->iv_myaddr, wh->i_addr1) &&
+		    !IEEE80211_IS_MULTICAST(wh->i_addr1)) {
+			IEEE80211_DISCARD_MAC(vap, IEEE80211_MSG_INPUT,
+			    wh->i_addr1, NULL, "%s", "not for us");
+			goto out;
+		}
 		IEEE80211_RSSI_LPF(ni->ni_avgrssi, rssi);
 		ni->ni_noise = nf;
 		if (HAS_SEQ(type) && !IEEE80211_IS_MULTICAST(wh->i_addr1)) {
Index: sys/net80211/ieee80211_ioctl.h
===================================================================
--- sys/net80211/ieee80211_ioctl.h	(revision 226808)
+++ sys/net80211/ieee80211_ioctl.h	(working copy)
@@ -96,6 +96,7 @@ struct ieee80211_stats {
 	uint32_t	is_rx_wrongbss;		/* rx from wrong bssid */
 	uint32_t	is_rx_dup;		/* rx discard 'cuz dup */
 	uint32_t	is_rx_wrongdir;		/* rx w/ wrong direction */
+	uint32_t	is_rx_wrongdst;		/* rx to wrong dst */
 	uint32_t	is_rx_mcastecho;	/* rx discard 'cuz mcast echo */
 	uint32_t	is_rx_notassoc;		/* rx discard 'cuz sta !assoc */
 	uint32_t	is_rx_noprivacy;	/* rx w/ wep but privacy off */

--Boundary-00=_UZVqOCBfTsaSL2w--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201110271502.12654.bschmidt>