35 ms·

I've always had mixed emotions about NICs that have hardware assisted offload features. I welcome the decrease in CPU utilization and increased throughput, but

I've always had mixed emotions about NICs that have hardware assisted offload features. I welcome the decrease in CPU utilization and increased throughput, but the NIC ends up being a complex system that very subtle bugs can lurk inside versus being a simple I/O device that a kernel driver controls. If there's denial of service hiding in there I wonder about what other security bugs might be lurking. It's scary stuff, and pretty much impossible to audit yourself. Edit: Also, I'm a little freaked-out that the EEPROM on the NIC can be modified easily with ethtool. I would have hoped for some signature verification. I guess I'm hoping for too much. Edit 2: I wonder if this isn't the same issue described here: https://bugzilla.redhat.com/show_bug.cgi?id=632650 https://bugzilla.redhat.com/show_bug.cgi?id=632650

jevinskie 14y ago
Be very afraid of PCI firmwares. You can insert rootkits there that have full access to RAM. An IOMMU can mitigate this threat.
- EvanAnderson 14y ago
  It sounds like, in this case, the OP is talking about the EEPROM holding code executed by the embedded coprocessor on the NIC (or, at least, lookup tables that the coprocessor uses) rather than a PCI option ROM that will be executed by the host computer's CPU. Depending on how the access to the EEPROM is performed (i.e. if such access is facilitated by the co-processor versus being read out directly from the EEPROM) I'd think an attacker could even implement "stealth" functionality to allow the compromised EEPROM to appear to be benign when audited. Depending on what functionality is being offloaded to the NIC (are there still NICs that do IPSEC and crypto offload?) there's the possibility for information disclosure vulnerabilities in the NIC itself. Yikes.
  - JoachimSchipper 14y ago
    > OP is talking about the EEPROM holding code executed by the embedded coprocessor on the NIC Yes, but this coprocessor has access to the host's PCI bus. That is enough to totally pwn the machine, since it gives read/write access to all memory (well, all memory below 4GB, IIRC, but that's enough.)
tgcyhv 14y ago
Isn't the EEPROM "patch" with ethtool simply sending the inoculating packet (the one with the "40" value) through the network stack?
- EvanAnderson 14y ago
  That's not the impression I'm getting from the article or the author's comments.
  - tgcyhv 14y ago
    I didn't have that impression either, but the implications are far too frightening.
api 14y ago
Makes me wonder if someday a bug (or "administrative function") in the firmware of a hardware device used at a major virtualization farm (EC2, Linode, VPS.NET, etc.) will be used to r00t the hardware nodes and then go wild all over everything there. Be afraid.
dfox 14y ago
The EEPROM does not contain the actual firmware, but it's configuration (or configuration of hardware itself in case of simple designs). Essentially any Fast Ethernet and newer NIC has some configuration EEPROM that is accessible by ethtool (which is what the tool is for after all). Common use cases for ethtool are persistently changing MAC address and fixing broken hardware (either to work around pre-existing HW bugs or to fix it after this EEPROM got somehow erased). Generally the EEPROM does not contain anything like executable code, although it probably can contain patches for microcode on many NICs.

jevinskie 14y ago

Be very afraid of PCI firmwares. You can insert rootkits there that have full access to RAM. An IOMMU can mitigate this threat.

EvanAnderson 14y ago
It sounds like, in this case, the OP is talking about the EEPROM holding code executed by the embedded coprocessor on the NIC (or, at least, lookup tables that the coprocessor uses) rather than a PCI option ROM that will be executed by the host computer's CPU. Depending on how the access to the EEPROM is performed (i.e. if such access is facilitated by the co-processor versus being read out directly from the EEPROM) I'd think an attacker could even implement "stealth" functionality to allow the compromised EEPROM to appear to be benign when audited. Depending on what functionality is being offloaded to the NIC (are there still NICs that do IPSEC and crypto offload?) there's the possibility for information disclosure vulnerabilities in the NIC itself. Yikes.
- JoachimSchipper 14y ago
  > OP is talking about the EEPROM holding code executed by the embedded coprocessor on the NIC Yes, but this coprocessor has access to the host's PCI bus. That is enough to totally pwn the machine, since it gives read/write access to all memory (well, all memory below 4GB, IIRC, but that's enough.)

tgcyhv 14y ago

Isn't the EEPROM "patch" with ethtool simply sending the inoculating packet (the one with the "40" value) through the network stack?

EvanAnderson 14y ago
That's not the impression I'm getting from the article or the author's comments.
- tgcyhv 14y ago
  I didn't have that impression either, but the implications are far too frightening.

api 14y ago

Makes me wonder if someday a bug (or "administrative function") in the firmware of a hardware device used at a major virtualization farm (EC2, Linode, VPS.NET, etc.) will be used to r00t the hardware nodes and then go wild all over everything there. Be afraid.

dfox 14y ago

The EEPROM does not contain the actual firmware, but it's configuration (or configuration of hardware itself in case of simple designs). Essentially any Fast Ethernet and newer NIC has some configuration EEPROM that is accessible by ethtool (which is what the tool is for after all). Common use cases for ethtool are persistently changing MAC address and fixing broken hardware (either to work around pre-existing HW bugs or to fix it after this EEPROM got somehow erased). Generally the EEPROM does not contain anything like executable code, although it probably can contain patches for microcode on many NICs.