https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286447
Bug ID: 286447
Summary: net80211: Insufficient length verification with HT
information elements
Product: Base System
Version: CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: wireless
Assignee: wireless@FreeBSD.org
Reporter: yichen.c...@gmail.com
Similar to Bug 286446, I can also put a zero length IE at the end of the IE
list with its type as HT capability. There is a length verification here, but
it only sets htcap to NULL and ieee80211_parse_beacon may still return 0:
https://github.com/freebsd/freebsd-src/blob/578cbd03f7a53eb23b71b560f8816f84f5a1461b/sys/net80211/ieee80211_input.c#L759
If the system tries to join the AP based on the beacon, it parses the IE list
again in ieee80211_ies_expand, this time assuming that the length of IEs are
already validated:
https://github.com/freebsd/freebsd-src/blob/578cbd03f7a53eb23b71b560f8816f84f5a1461b/sys/net80211/ieee80211_node.c#L974
The subsequent use of htcap may therefore read out of bounds again:
https://github.com/freebsd/freebsd-src/blob/578cbd03f7a53eb23b71b560f8816f84f5a1461b/sys/net80211/ieee80211_node.c#L980
The same issue applies to HT cap and info as well as VHT cap and info, although
the latter is not in use AFAIK. I noticed that the information from the
out-of-bounds read seem to be largely used in configuring HT for 802.11n and
none of it is easily obtainable over the air by an attacker, so the impact
should be rather small.
--
You are receiving this mail because:
You are the assignee for the bug.
