MSFT released a patch for CVE-2024-30078 (Wi-Fi Driver RCE) on June cumulative update, however details on the advisory have been very limited.
I'm leaving some quick notes from a quick reverse engineering of the patch that hopefully will shed a little more light on the issue. 🧵
I'm leaving some quick notes from a quick reverse engineering of the patch that hopefully will shed a little more light on the issue. 🧵
I am not an expert on wireless network protocols so feel free to correct me or add up on the provided info in the comments or through a DM.
The patch targets Dot11Translate80211ToEthernetNdisPacket() of the native wifi driver (nwifi.sys).
The patch targets Dot11Translate80211ToEthernetNdisPacket() of the native wifi driver (nwifi.sys).
The patch expands on a previous check at the beginning of the function which is described in the pseudocode below:
MDL_packetSize = MDL->ByteCount;
if (MDL->ByteCount < (MAC_frame_size + 8))
return NDIS_STATUS_INVALID_PACKET;
MDL_packetSize = MDL->ByteCount;
if (MDL->ByteCount < (MAC_frame_size + 8))
return NDIS_STATUS_INVALID_PACKET;
The above check ensures the received packet size is greater than the size of the physical and link layer frames + 8.
The function seems to expect a packet with a 802.11 frame followed by a 802.2 LLC header which contains a two-octet field with the etherType.
The function seems to expect a packet with a 802.11 frame followed by a 802.2 LLC header which contains a two-octet field with the etherType.
On the specific case where etherType field is 0x8100 (VLAN-tagged frame), the patch introduces an aditional check that didn't exist on the vulnerable version:
if (Feature_1281542463() && MDL_packetSize < *(netBuffer->MAC_frame_size) + 12)
return NDIS_STATUS_INVALID_PACKET;
if (Feature_1281542463() && MDL_packetSize < *(netBuffer->MAC_frame_size) + 12)
return NDIS_STATUS_INVALID_PACKET;
The expands on the previous check on 4 additional bytes which seem to accomodate for a 802.1Q header containing the VLAN identifier.
Its possible to devise a detection sig based on the etherType value since most people won't be using vlan tagging over wifi.
Its possible to devise a detection sig based on the etherType value since most people won't be using vlan tagging over wifi.
The information above also strongly suggests the vulnerability is reachable from an adjacent wireless device that does not need to be authenticated on the same network as the target.
This is as far as I'll go into the vulnerability in public but should provide enough pointers to follow up if you're interested in it. Also beware of PoC's online that have nothing to do with the issue at hand.
Hope you enjoy.
Hope you enjoy.
I need to make a correction. Upon closer inspection it seems you need to be authenticated on the same network as the victim.
I wonder if @KunlunLab are planning a talk or blogpost on this vulnerability.
I wonder if @KunlunLab are planning a talk or blogpost on this vulnerability.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
