Why is the networking business dozing through Meltdown/Spectre?
There may be some vulnerable cores in switches, but getting to them is hard
In the seven weeks since The Register broke the news of the Meltdown/Spectre speculative execution vulnerabilities, nearly every corner of the industry has scrambled to patch, re-patch, and work out how to Spectre-proof the world.
Except for Ethernet switch vendors, who with a very few exceptions haven't even troubled to make statements about the bugs.
We know that vulnerable architectures exist in switches: there's an awful lot of ARM cores shunting packets around LANs and data centres.
So what gives? Why does the Ethernet market get to doze through one of the most painful patches the tech sector has ever suffered?
If you're familiar with how Ethernet works, you already know the answer, but the El Reg inbox is a reminder that not everybody in tech works with networking. So here, for the Ethernet-curious, is the answer to why Meltdown and Spectre won't expose your switch's deepest, darkest secrets.
Hate to ruin your day, but... Boffins cook up fresh Meltdown, Spectre CPU design flaw exploitsREAD MORE
Our thanks to Australian hardware designer Justin Clacherty, CEO of Redfish Systems, for discussion and input to this article.
We started by asking the giant-of-networking-giants, Cisco, two questions: can Meltdown/Spectre be exploited through the data plane of a switch? And, can the vulnerabilities be exploited through the control plane of an Ethernet switch?
We got the answers we expected – “no”, in both cases – and Cisco referred back to what it has already disclosed about the vulnerabilities (Switchzilla rates these as “medium” impact).
Cisco's discussion is, naturally enough, about Cisco products – but it's worth understanding why, if you search major Ethernet vendors' sites for Meltdown/Spectre statements, you'll find precious little.
From Cisco's point of view, Meltdown/Spectre attacks are architecturally unlikely for most networking hardware. As the company told The Register in an e-mail: “in order to exploit any of these vulnerabilities, an attacker must be able to run crafted code on an affected device … There is no vector to exploit them.”
And there are reasons such statements apply to pretty much any Ethernet switch.
Data plane attacks
Even if an Ethernet switch used a vulnerable architecture (ARM, for example) as the packet processor, a remote attacker has no way to inject data into an Ethernet frame to trigger the vulns.
Why not? Because from outside the router, you have no control over what's sent to the switches.
When you, the attacker, communicate with a target network, you're using the IP stack to send packets to a router – you're using the Internet layer (in the IP stack model), which corresponds to Layer 3 (the network layer) in the OSI model.
It's the router that takes what's in the data field of the IP packet, formats it (with appropriate fragmentation) into Ethernet frames, and puts it on the wire.
If a data plane attack were feasible, you'd need access to the LAN to launch it. Even then, as an evil insider, what can you do to an Ethernet switch port? Below is a representation of an Ethernet frame.
|Start of frame delimiter||1 octet|
|MAC destination||6 octets|
|MAC source||6 octets|
|Optional 802.1q tag||4 octets|
|Ethertype / length||2 octets|
|CRC checksum||4 octets|
|Interpacket gap||12 octets|
Nearly most of the frame is signalling information of some kind – that's what the switch looks at. It's not interested in the payload.
It's also noting that most of the signalling fields are short, so you'd have to craft an attack that needed only a handful of bytes.
For example, you might somehow craft a six-octet (48 byte) attack based on a spoofed MAC address. So you replace 4c:8d:79:d8:37:5c with a string that triggers Meltdown/Spectre, and achieve what?
You get access to the packet processor's kernel memory, which sounds bad, but the packet processor isn't like a big server hosting hundreds of VMs. Most of what a packet processor stores is MAC addresses, so it can quickly and at huge scale, remember associations between different ports, and switch your packet.
What's most likely to happen in any successful attack on an Ethernet switch is that you crash the network, which is bad. But if you're inside the data centre, you're in a position to do that anyway without having to tinker with speculative execution design flaws.
The control plane
So what about the control plane of the switch? The fully-featured computer that acts as the all-seeing eye of the network?
Those controllers might well use vulnerable architectures, but that doesn't mean the vulnerabilities are exploitable – or that an exploit is usable.
For a start, Meltdown and Spectre are privilege escalation bugs – and the management processes on an Ethernet switch are (in many or most cases) running as root, and they're not sharing their on-switch execution space with other user-privileged processes.
Cisco also emphasised to us that switches are locked-down devices that don't run custom code. In other words, even if the control plane sits on a vulnerable architecture, an attacker can't just drop traffic on the management port and get it executed. You'd have to go to a lot more effort, for example spoofing the official Cisco code-signing so you can flash some attack code onto the switch.
If you've got a login, you can talk to the switch's management port, you're already in control of the network, so why bother?
So far, I've stuck to discussing proprietary environments. What about the burgeoning “white box” switch market, in which the boxes ship with packet processors controlled by whatever operating system the user puts on the metal?
What I wrote above about the data plane still applies, but yes, it's feasible that a custom Linux build on top of the switch might be vulnerable.
The attack scenario still sucks: there probably isn't a path from the Internet to the management port, and if you can get to the management port, there are better ways to spend your time. ®