mac80211: unencrypted packet vulnerability

mac80211: unencrypted packet vulnerability

[Johannes Berg]

Hi,

As I just found, mac80211 is susceptible to an attack where the attacker
simply sends frames it wants us to see unencrypted instead of bothering
with replay attacks or such. This could possibly cause us to reply to
these frames or worse yet, a mac80211 based AP could encrypt the frames
and broadcast them if the attacker uses a MAC address of another station
that is properly associated!

The reason is that ieee80211_rx_h_drop_unencrypted() drops unencrypted
frames, but only if "sdata->drop_unencrypted" is set which never
happens!

I'd offer the patch below but that's hardly complete. And then what
about wext's encode and IW_ENCODE_RESTRICTED? Isn't that exactly the
same thing? ieee80211 treats it that way and I can't find docs other
than this paragraph from iwconfig's man page

  The  security  mode  may  be open or restricted, and its meaning
  depends on the card used. With  most  cards,  in  open  mode  no
  authentication  is  used  and  the  card  may  also  accept non-
  encrypted sessions, whereas in restricted  mode  only  encrypted
  sessions  are  accepted  and the card will use authentication if
  available.

And you can hardly claim that this defines the semantics of the flag
well enough to be able to implement it. Especially since it uses
keywords defined by 802.11 with a totally different meaning! I love you
Jean, thanks for creating the most undefined API I ever saw.

Even with this patch, however, we still don't have drop_unencrypted set
with plain WEP networks. For IBSS it defaults to the PRIVACY bit in the
BSS information, but for managed networks this is not done. I find this
rather disconcerting.

Should we set this to the value of the privacy bit after we join a BSS
like we do for the IBSS case?

The patch below is necessary for wpa_supplicant to be able to set the
drop_unencrypted setting, but I'm not convinced it actually needs to be
able to set it. Can't the kernel just do a sane default?

Considering the AP case, on the other hand, hostapd will need to be able
to set the setting since we don't actually look into the beacon it tells
us to transmit. But hostapd on the other hand doesn't even invoke the
iwauth ioctl! I have to admit to being rather confused.

johannes

--- everything.orig/net/mac80211/ieee80211_ioctl.c	2007-11-21 23:34:10.895859212 +0100
+++ everything/net/mac80211/ieee80211_ioctl.c	2007-11-21 23:34:37.295855632 +0100
@@ -928,6 +928,9 @@ static int ieee80211_ioctl_siwauth(struc
 	case IW_AUTH_RX_UNENCRYPTED_EAPOL:
 	case IW_AUTH_KEY_MGMT:
 		break;
+	case IW_AUTH_DROP_UNENCRYPTED:
+		sdata->drop_unencrypted = !!data->value;
+		break;
 	case IW_AUTH_PRIVACY_INVOKED:
 		if (sdata->type != IEEE80211_IF_TYPE_STA)
 			ret = -EINVAL;

Re: mac80211: unencrypted packet vulnerability

[Dan Williams]

On Thu, 2007-11-22 at 00:01 +0100, Johannes Berg wrote:
> Hi,
> 
> As I just found, mac80211 is susceptible to an attack where the attacker
> simply sends frames it wants us to see unencrypted instead of bothering
> with replay attacks or such. This could possibly cause us to reply to
> these frames or worse yet, a mac80211 based AP could encrypt the frames
> and broadcast them if the attacker uses a MAC address of another station
> that is properly associated!
> 
> The reason is that ieee80211_rx_h_drop_unencrypted() drops unencrypted
> frames, but only if "sdata->drop_unencrypted" is set which never
> happens!
> 
> I'd offer the patch below but that's hardly complete. And then what
> about wext's encode and IW_ENCODE_RESTRICTED? Isn't that exactly the
> same thing? ieee80211 treats it that way and I can't find docs other
> than this paragraph from iwconfig's man page

IW_ENCODE_RESTRICTED is used in a few places to mean Shared Key auth
mode, since there's no other way in WEXT to handle the difference
between Shared Key and Open System, and because drivers usually don't
(and really shouldn't) by trying to cycle between auth modes themselves.

Dan

>   The  security  mode  may  be open or restricted, and its meaning
>   depends on the card used. With  most  cards,  in  open  mode  no
>   authentication  is  used  and  the  card  may  also  accept non-
>   encrypted sessions, whereas in restricted  mode  only  encrypted
>   sessions  are  accepted  and the card will use authentication if
>   available.
> 
> And you can hardly claim that this defines the semantics of the flag
> well enough to be able to implement it. Especially since it uses
> keywords defined by 802.11 with a totally different meaning! I love you
> Jean, thanks for creating the most undefined API I ever saw.
> 
> Even with this patch, however, we still don't have drop_unencrypted set
> with plain WEP networks. For IBSS it defaults to the PRIVACY bit in the
> BSS information, but for managed networks this is not done. I find this
> rather disconcerting.
> 
> Should we set this to the value of the privacy bit after we join a BSS
> like we do for the IBSS case?
> 
> The patch below is necessary for wpa_supplicant to be able to set the
> drop_unencrypted setting, but I'm not convinced it actually needs to be
> able to set it. Can't the kernel just do a sane default?
> 
> Considering the AP case, on the other hand, hostapd will need to be able
> to set the setting since we don't actually look into the beacon it tells
> us to transmit. But hostapd on the other hand doesn't even invoke the
> iwauth ioctl! I have to admit to being rather confused.
> 
> johannes
> 
> --- everything.orig/net/mac80211/ieee80211_ioctl.c	2007-11-21 23:34:10.895859212 +0100
> +++ everything/net/mac80211/ieee80211_ioctl.c	2007-11-21 23:34:37.295855632 +0100
> @@ -928,6 +928,9 @@ static int ieee80211_ioctl_siwauth(struc
>  	case IW_AUTH_RX_UNENCRYPTED_EAPOL:
>  	case IW_AUTH_KEY_MGMT:
>  		break;
> +	case IW_AUTH_DROP_UNENCRYPTED:
> +		sdata->drop_unencrypted = !!data->value;
> +		break;
>  	case IW_AUTH_PRIVACY_INVOKED:
>  		if (sdata->type != IEEE80211_IF_TYPE_STA)
>  			ret = -EINVAL;
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mac80211: unencrypted packet vulnerability

[Jouni Malinen]

On Mon, Nov 26, 2007 at 10:37:18AM -0500, Dan Williams wrote:
> On Thu, 2007-11-22 at 00:01 +0100, Johannes Berg wrote:
> > I'd offer the patch below but that's hardly complete. And then what
> > about wext's encode and IW_ENCODE_RESTRICTED? Isn't that exactly the
> > same thing? ieee80211 treats it that way and I can't find docs other
> > than this paragraph from iwconfig's man page

I'd guess it depends on who you ask.. For me, it was exactly this, but
I've certainly seen another functionality being claimed for it, i.e.,
this:

> IW_ENCODE_RESTRICTED is used in a few places to mean Shared Key auth
> mode, since there's no other way in WEXT to handle the difference
> between Shared Key and Open System, and because drivers usually don't
> (and really shouldn't) by trying to cycle between auth modes themselves.

There wasn't, but there is now. I added an explicit 802.11
authentication algorithm parameter (IW_AUTH_80211_AUTH_ALG) in WE-18 in
order to make it somewhat easier to push people away from misusing
IW_ENCOE_RESTRICTED.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: mac80211: unencrypted packet vulnerability

[Jouni Malinen]

On Thu, Nov 22, 2007 at 12:01:37AM +0100, Johannes Berg wrote:

> As I just found, mac80211 is susceptible to an attack where the attacker
> simply sends frames it wants us to see unencrypted instead of bothering
> with replay attacks or such. This could possibly cause us to reply to
> these frames or worse yet, a mac80211 based AP could encrypt the frames
> and broadcast them if the attacker uses a MAC address of another station
> that is properly associated!

> The reason is that ieee80211_rx_h_drop_unencrypted() drops unencrypted
> frames, but only if "sdata->drop_unencrypted" is set which never
> happens!

Hmm.. What happened to the original code that had (rx->key ||
rx->sdata->drop_unencrypted)?

The drop_unencrypted was originally designed as just an extra layer of
protection and it was not really needed in most configurations. There
might have been some odd corner cases where it was needed in
multi-SSID/BSSID case, but other than that, the rx->key part would have
taken care of this.

> The patch below is necessary for wpa_supplicant to be able to set the
> drop_unencrypted setting, but I'm not convinced it actually needs to be
> able to set it. Can't the kernel just do a sane default?

I thought it did.. By the use of rx->key here, not by use of
drop_unencrypted. Anyway, like I said, drop_unencrypted is an extra
layer of security, so having possibility of using it may be nice safety
net should something else go wrong in the RX logic.

> Considering the AP case, on the other hand, hostapd will need to be able
> to set the setting since we don't actually look into the beacon it tells
> us to transmit. But hostapd on the other hand doesn't even invoke the
> iwauth ioctl! I have to admit to being rather confused.

The Devicescape version of hostapd did.. I do not remember why this was
not merged, but I would assume it was just something that I never got to
and since it was using a private ioctl for setting the parameter that
option already disappeared. Sure, it would be reasonable to add support
for it now that the parameter is available with WE-18.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: mac80211: unencrypted packet vulnerability

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1398 bytes --]


> > The reason is that ieee80211_rx_h_drop_unencrypted() drops unencrypted
> > frames, but only if "sdata->drop_unencrypted" is set which never
> > happens!
> 
> Hmm.. What happened to the original code that had (rx->key ||
> rx->sdata->drop_unencrypted)?

Hmm. Yes, that'd help. Seems that got lost at some point. I'll take a
look and fix it up.

> I thought it did.. By the use of rx->key here, not by use of
> drop_unencrypted. Anyway, like I said, drop_unencrypted is an extra
> layer of security, so having possibility of using it may be nice safety
> net should something else go wrong in the RX logic.
> 
> > Considering the AP case, on the other hand, hostapd will need to be able
> > to set the setting since we don't actually look into the beacon it tells
> > us to transmit. But hostapd on the other hand doesn't even invoke the
> > iwauth ioctl! I have to admit to being rather confused.
> 
> The Devicescape version of hostapd did.. I do not remember why this was
> not merged, but I would assume it was just something that I never got to
> and since it was using a private ioctl for setting the parameter that
> option already disappeared. Sure, it would be reasonable to add support
> for it now that the parameter is available with WE-18.

I think I did a patch already. I need to review all my patches and post
those that are appropriate.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]