A random tweet¹ pointed me to Vulnerability Note VU#855201 that documents four vulnerabilities exploiting a weird combination of LLC and VLAN headers can bypass layer-2 security on most network devices.

The security researcher who found the vulnerability also provided an excellent in-depth description focused on the way operating systems like Linux and Windows handle LLC-encapsulated IP packets. Here’s the CliffNotes version focused more on the hardware switches. Even though I tried to keep it simple, you might want to read the History of Ethernet Encapsulation before moving on.

This is how an Ethernet frame using a VLAN tag (802.1q) or frame priority (802.1p – VLAN field is set to zero) should look like:

┌─────────────┬───────┬────────┬──────────┬────────────────────┐
│MAC addresses│VLAN ET│VLAN HDR│Payload ET│Payload             │
└─────────────┴───────┴────────┴──────────┴────────────────────┘

• The frame is using Ethernet II encapsulation
• VLAN EtherType (0x8100) is the first EtherType in the frame
• VLAN header follows the VLAN EtherType
• Payload follows the VLAN header, starting with payload EtherType (0x0800 for IPv4, 0x86DD for IPv6, …)

LLC2 encapsulation is used on all other LAN media (example: WiFi). The same packet sent on WiFi looks like this:

┌─────────────┬────────┬───────┬────────┬──────────┬───────────┐
│MAC addresses│LLC SNAP│VLAN ET│VLAN HDR│Payload ET│Payload    │
└─────────────┴────────┴───────┴────────┴──────────┴───────────┘

• The frame is using LLC Type 1 encapsulation
• LLC header specifies SNAP encapsulation – the rest of the frame will use EtherTypes
• VLAN EtherType (0x8100) is the first EtherType in the frame
• VLAN header follows the VLAN EtherType
• Payload follows the VLAN header, starting with payload EtherType (0x0800 for IPv4, 0x86DD for IPv6)

What do you think would happen if someone sends WiFi-formatted packet on Ethernet?

• Most operating systems would happily receive it, process the slightly bizarre sequence of headers, and send the IP datagram to the IP stack.
• Most forwarding hardware would be totally confused and fail to parse the inner payload as it does not expect such a layering of protocol headers.

What’s the impact of that parsing failure? You can’t get anything forwarded into another subnet if the forwarding device doesn’t parse the incoming frame as containing a layer-3 packet, but you can get an obfuscated packet past a layer-2 ACL that does not have a “deny all” at the end.

Unfortunately, the defaults that switch vendors have to implement to reduce their support costs² is to forward all packets within a layer-2 segment and drop only those malicious packets that they recognize (for example, IPv6 RA messages coming from an untrusted source). The unusual (and probably invalid, but who’s counting) stacking of protocol headers thus allows an intruder to bypass any layer-2 security measure like layer-3 ACLs on layer-2 ports, ARP/ND inspection, DHCP guard or RA guard.

Arista’s security advisory clearly identifies these challenges (if you know where to look) and recommends using a layer-2 ACL that drops any frames where the hardware parser stopped at 802.1q or 802.1ad EtherType. They also recommend a much better solution to block another vulnerability – stricter ACL that permits only IPv4, IPv6, and ARP.

Long story short: The vulnerabilities are an interesting exploit of too many encapsulation options, but they cannot be used to implement VLAN hopping, and the sky is still not falling. They do present an interesting lesson in having too many standards, but I doubt that many people working for a networking vendor or participating in a standards body would be interested in considering it.