Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Packets of Death

blog.krisk.org

Post reply on HN
Print view View original

41–50 of 119 posts

Re: Packets of Death

#41

Post by tgcyhv »

EvanAnderson wrote: post #5

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…

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

Re: Packets of Death

#42

Post by jacquesm »

samstave wrote: post #37
EvanAnderson wrote: post #25

Earlier quoted context omitted.

It sounds like the vulnerability could be used to bring down any machine you can send an arbitrary Ethernet frame to. (I immediately wonder if it works for broadcast frames? Sounds like a way to take down a LAN full of machines quickly if it does.) Edit: Per http://www.kriskinc.com/intel-pod it does work on broadcast frames. Yikes!

Heh, yeah and he pretty much gives all the info on how to create the attack. The test would be to find out how common that particular NIC is out there - and grab a few and test out his method. Looks like it would be fairly trivial to setup duplication given the author did all the heavy lifting in finding this. Putting a small AWS bot-net up that just sweeps massive IP blocks would be easy - heck you could do it reall…

Just to be on the safe side I just checked all my machines, the majority have broadcom cards, the three that have intel cards are all another type. I think I'll sleep soundly tonight but I felt compelled to check.

Re: Packets of Death

#43

Post by wisty »

Jabbles wrote: post #21
wglb wrote: post #10

Very good detective work. However, a small suggestion, given: I’ve been working with networks for over 15 years and I’ve never seen anything like this. I doubt I’ll ever see anything like it again. This is a very excellent case for fuzz testing. My thinking is that you want to whip up your Ruby and your EventMachine and Redis going and run a constant fuzz with all sorts of packets in your pre-shipping lab. The idea i…

Surely that's the manufacturer's job. Since it's caused by a specific byte at a specific place, surely you'd only need to fuzz an average of 256 packets (of the required length) to find it... which suggests it wasn't done at all... zero...

Or it was done once, and the "inoculation" byte came first.

There were 4 buggy bytes. 3 would crash the card. 1 would fix the card ("inoculating" it). If they only fuzzed once, or fuzzed with the same dataset (random.seed(1) // seed chosen at random), then they wouldn't catch it.

Even then, it's pretty sloppy.

Re: Packets of Death

#44

Post by EvanAnderson »

tgcyhv wrote: post #41
EvanAnderson wrote: post #5

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…

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

That's not the impression I'm getting from the article or the author's comments.

Re: Packets of Death

#45

Post by vacri »

meshko wrote: post #18

I 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.

"Closed: Works for me"

Re: Packets of Death

#46

Post by samstave »

jacquesm wrote: post #42
samstave wrote: post #37

Earlier quoted context omitted.

Heh, yeah and he pretty much gives all the info on how to create the attack. The test would be to find out how common that particular NIC is out there - and grab a few and test out his method. Looks like it would be fairly trivial to setup duplication given the author did all the heavy lifting in finding this. Putting a small AWS bot-net up that just sweeps massive IP blocks would be easy - heck you could do it reall…

Just to be on the safe side I just checked all my machines, the majority have broadcom cards, the three that have intel cards are all another type. I think I'll sleep soundly tonight but I felt compelled to check.

That was a very responsible thing to do. :)

Re: Packets of Death

#47

Post by jevinskie »

EvanAnderson wrote: post #28
jerdfelt wrote: post #24

I ran into a similar problem with an Intel motherboard about 10 years ago. We had problems when some NFS traffic would end up getting stalled. Our NFS server would use UDP packets larger than the MTU and they would end up getting fragmented. Turns out the NIC would not look at the fragmentation headers of the IP packet and always assume a UDP header was present. From time to time, the payload of the NFS packet would…

Reading about the OP's issue got me to a doc from Intel ( http://www.intel.com/content/dam/doc/application-note/sideba... ) re: the "NC Sideband Interface", which sounds like the place where the bug that bit you "lives". Reading over that doc made me shudder a few times, thinking about the complexity and, thus, potential bugs that could be lurking there. I wonder if the OP's bug was related, too. Having the NIC inspe…

"IPMI operates independently of the OS and allows administrators to manage a system remotely even without an OS, system management software, and even if the monitored system is powered off (along as it is connected to a power source). IPMI can also function after an OS has started, offering enhanced features when used with system management software."

Yikes! Sounds like system management mode in a BIOS!

Re: Packets of Death

#48

Post by IheartApplesDix »

engtech wrote: post #6

As 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…

Well, it's very weird if you understand anything about Network protocols. It's a layer of complexity that shouldn't be being touched by your NIC, so there shouldn't be a bug there because there shouldn't be code there.

Re: Packets of Death

#49

Post by EvanAnderson »

jevinskie wrote: post #47
EvanAnderson wrote: post #28

Earlier quoted context omitted.

Reading about the OP's issue got me to a doc from Intel ( http://www.intel.com/content/dam/doc/application-note/sideba... ) re: the "NC Sideband Interface", which sounds like the place where the bug that bit you "lives". Reading over that doc made me shudder a few times, thinking about the complexity and, thus, potential bugs that could be lurking there. I wonder if the OP's bug was related, too. Having the NIC inspe…

"IPMI operates independently of the OS and allows administrators to manage a system remotely even without an OS, system management software, and even if the monitored system is powered off (along as it is connected to a power source). IPMI can also function after an OS has started, offering enhanced features when used with system management software." Yikes! Sounds like system management mode in a BIOS!

It's worse than that. It's not BIOS-- it's a freestanding computer.

You'll enjoy this (or be horrified by it): http://fish2.com/ipmi/itrain.html

Re: Packets of Death

#50

Post by altcognito »

huhtenberg wrote: post #14
altcognito wrote: post #11

http://en.wikipedia.org/wiki/Ping_of_death

That was an OS-level bug, it's far less exciting.

I'll agree it's more interesting in that the end-result was a box that required a hard boot, but still these two issues aren't that distantly related: it effected routers and many, many OS platforms, so it's not as if it was related to some implementation detail that MS left out of Windows.

Correct me if I'm wrong (no, seriously) -- aren't both "packets of death" just poor handling of said malformed packets? Violations of their respective protocols? (TCP/SIP)

Post reply on HN