Re: mac80211: unencrypted packet vulnerability

[Johannes Berg <johannes@sipsolutions.net>]

[-- 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 --]