[GH-ISSUE #110] [security] [dhcp] xdp filter should check against ip options #27

New issue

Closed

opened 2026-03-04 01:34:12 +03:00 by kerem · 0 comments

kerem commented

2026-03-04 01:34:12 +03:00

Owner

Originally created by @lts-rad on GitHub (Jan 28, 2023).
Original GitHub issue: https://github.com/spr-networks/super/issues/110

it was reported that the xdp filter does not handle ip options properly, and will need to be updated for VLAN tagged traffic as well.

Background:

The XDP filter helps enforce the zero-trust security model, where a per device password is assigned
Wired devices currently do not have any such security guarantee against MAC spoofing until VLAN tags are supported.
IP options could be used to have a device with one MAC address/key, create a DHCP request for a different device's MAC address

Impact:

This would result in an arp entry and route to the wrong WiFi VLAN (to the malicious device)
Because the MAC is used to inform wifi encryption , and ap_isolate=1 results in unique GTKs, it was previously observed (when this filter was written) that the malicious device receives encrypted traffic and can send garbaled packets but can not send/receive plaintext traffic.
The main impact is expected to mainly be side-channel information about packets/traffic size
Additional attacks could be possible due to logic state issues in the wifi firmware itself, falling under the category of frag attacks (https://www.fragattacks.com/)

https://github.com/spr-networks/super/blob/main/wifid/code/filter_dhcp_mismatch.c

The code should be updated. When a packet is UDP and on port 67 it should also

Check that h_proto in the ethernet header matches IPv4
Check that frag_off is 0
Check that ip_hl does not include any options

Originally created by @lts-rad on GitHub (Jan 28, 2023). Original GitHub issue: https://github.com/spr-networks/super/issues/110 it was reported that the xdp filter does not handle ip options properly, and will need to be updated for VLAN tagged traffic as well. Background: - The XDP filter helps enforce the zero-trust security model, where a per device password is assigned - Wired devices currently do not have any such security guarantee against MAC spoofing until VLAN tags are supported. - IP options could be used to have a device with one MAC address/key, create a DHCP request for a different device's MAC address Impact: - This would result in an arp entry and route to the wrong WiFi VLAN (to the malicious device) - Because the MAC is used to inform wifi encryption , and ap_isolate=1 results in unique GTKs, it was previously observed (when this filter was written) that the malicious device receives encrypted traffic and can send garbaled packets but can not send/receive plaintext traffic. - The main impact is expected to mainly be side-channel information about packets/traffic size - Additional attacks could be possible due to logic state issues in the wifi firmware itself, falling under the category of frag attacks (https://www.fragattacks.com/) https://github.com/spr-networks/super/blob/main/wifid/code/filter_dhcp_mismatch.c The code should be updated. When a packet is UDP and on port 67 it should also 1. Check that h_proto in the ethernet header matches IPv4 2. Check that frag_off is 0 3. Check that ip_hl does not include any options