[PATCH 3/7] TDLS: allow extra erroneous IEs in all packets

Jouni Malinen j
Mon Feb 23 09:42:59 PST 2015


On Mon, Feb 23, 2015 at 03:56:48PM +0200, Arik Nemtsov wrote:
> I don't have a sniffer capture (or event the wpa_s log anymore), but
> we encountered this on an incoming TDLS teardown packet.

I can understand teardown as a relevant case. It is the other messages
that I was more curious about since they should be long enough to avoid
hitting this issue.

> For this case I'm not sure what it was, but for previous cases, the
> extra data looked like an IE from the CCX protocol (which I don't
> really know).
> But does it matter what it really is? IMO we should be lenient in what
> we accept, as long as the MIC is not damaged.

It does not matter as far as the actual implementation is concerned. It
does matter as far as the commit message and code comments are
concerned. As far as I can tell, the real issue here is in the AP
padding IEEE 802.11 Data frames that are shorter than minimum Ethernet
frames with some arbitrary data. If you are seeing things like IEs from
CCX (etc.), that would be a potential sign of information disclosure
vulnerability, i.e., maybe some arbitrary AP memory getting used as
padding.

> For the case in hand, we had a peer that was out of sync in its TDLS
> state with us, when talking through the cisco 1260, which is a pretty
> unpleasant experience.

Understood and agreed (I did already apply the patch). I just want to
make sure there is now new interop issue reported here and the main
reason for the issue can still be assumed to be in that incorrect
padding of IEEE 802.11 Data frames when going through the stack
somewhere within the AP.

-- 
Jouni Malinen                                            PGP id EFC895FA



More information about the Hostap mailing list