Packets of Death
11–20 of 119 posts
Re: Packets of Death
#12Intense!
Re: Packets of Death
#13As someone who works with FPGAs/ASICs, this isn't that weird. Everything gets serialized/deserialized these days, so there's all kinds of boundary conditions where you can flip just the right bit and get the data to be deserialized the wrong way. What's more interesting is that it bypasses all of the checks to prevent this from happening. Here is the wiki page on the INVITE OF DEATH which sounds like the problem you…
> Everything gets serialized/deserialized these days, ... and get the data to be deserialized the wrong way.
Can you elaborate? I recognize the words, but not the meaning.
Re: Packets of Death
#14http://en.wikipedia.org/wiki/Ping_of_death
That was an OS-level bug, it's far less exciting.
Re: Packets of Death
#15That is great HN content!
Debugging deep down the rabbit hole, until you find a bug in the NIC EEPROM - and the disbelief many show when hearing a software message can bring down a NIC.
I for one would enjoy reading more content like this on HN that what qualifies as best as a friday-night hack
Re: Packets of Death
#16Wow, I've run into what seems to be the same problem with this controller before. We "fixed" it by upgrading the e1000 driver.
Re: Packets of Death
#17I'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…
Be very afraid of PCI firmwares. You can insert rootkits there that have full access to RAM. An IOMMU can mitigate this threat.
Re: Packets of Death
#18I have mixed feelings about the write up. I think it gets clear pretty early on that the issue is in the NIC hardware at which point it is time to stop wasting your time investigating problem you can't fix and start contacting the vendor.
Re: Packets of Death
#19I'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…
Be very afraid of PCI firmwares. You can insert rootkits there that have full access to RAM. An IOMMU can mitigate this threat.
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.
Re: Packets of Death
#20Persistent bugger.
"With a modified HTTP server configured to generate the data at byte value (based on headers, host, etc) you could easily configure an HTTP 200 response to contain the packet of death - and kill client machines behind firewalls!"
That's worrisome, I'll bet there are lots of not-so-nice guys trying to figure out a way to do just that. There must be tons of server hardware out there with these cards in them.