Live data from Hacker News

Packets of Death

blog.krisk.org

91–100 of 119 posts

Re: Packets of Death

#91

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…

"he pretty much gives all the info on how to create the attack"

And the more disruptive the attack the better. Because it shall help have better process put into place, at every level, to mitigate such issues in the future.

The last thing I want is a deadly packet not breaking havoc only because it's payload is not known.

If a single packet can bring down a big part of the net, then by all means make it happen and make it as bad you can. And then we can start thinking about how to build a more reliable and more secure net.

Re: Packets of Death

#93

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…

"he pretty much gives all the info on how to create the attack" And the more disruptive the attack the better. Because it shall help have better process put into place, at every level, to mitigate such issues in the future. The last thing I want is a deadly packet not breaking havoc only because it's payload is not known. If a single packet can bring down a big part of the net, then by all means make it happen and ma…

Oh, I agree.

I have a total digital schadenfreude for such things, except for stuxnet and duqu which are evil and scary.

Re: Packets of Death

#94
post #36

Earlier quoted context omitted.

> the disbelief many show when hearing a software message can bring down a NIC. Shouldn't be a surprise to anyone. Firmware is just software, and it necessarily deals with raw bytes. Not really surprising that it can contain bugs that are triggered by certain byte patterns.

In this light, the surprising thing is that we don't hear about firmware bugs more often. Have manufacturers have been doing a great job of keeping things simple and exhaustively testing, driven by the fear of the losses an incident and recall would cause?

In my experience many software developers are pretty ignorant about hardware issues since they rarely have to deal with hardware beyond their desktops or laptops. If you live in the IT world for a while and work with enterprise-grade equipment these kinds of problems actually crop up a lot.

For any given piece of gear in your server room there is likely a massive list of firmware bugs for it and its subcomponents. Sometimes they are fixed, sometimes not. When you run in to one that affects and need to deploy a firmware fix to dozens or hundreds of servers, it's not a whole lot of fun.

Re: Packets of Death

#95
post #73

So is it only the byte at 0x47f that matters? Could you just send a packet filled with 0x32 0x32 0x32 0x32 0x32 to trigger this? (Like, download a file full of 0x32s?) Or does it have to look like a SIP packet? You'd think the odds of getting a packet with 0x32 in position 0x47f is almost 1/256 per packet? So why aren't these network cards falling over everywhere every few seconds?

Probably because there is a 2/256 chance of getting sent the inoculation value. But it's a good question.

Later in the article it states that any value other than 0x31, 0x32 or 0x33 acts as an "inoculation value", so that would be a 253/256 chance for each packet of at least 1151 bytes.

Re: Packets of Death

#96
post #79
post #55

Earlier quoted context omitted.

you conveniently omitted the part in which you walk to the racks and reboot them all.

Right! Except it sounds worse--sounded like you needed to cycle power to bring them back.

Luckily there's usually a convenient switch for power-cycling a whole suite of racks at once ;)

Re: Packets of Death

#97
Great diligence! I had 1G hubs lockup with Intel 82578DM. I was too lazy track it down, so I just dropped the speed to 100M, which made it work.

Re: Packets of Death

#98
This somehow reminds me of the slammer SQL worm. A simply formed single packet caused a tsunami over the internet.

Personally, I am not at all surprised that this sort of thing exists. I'm sure there's lots more defects out there to be found. turning completeness is a cruel master.

Re: Packets of Death

#100
Kielhofner is a pretty awesome guy. I met him a couple of times "back in the day" at Astricon conferences when he was hacking together Astlinux.

He was instrumental in taming the Soekris and Alix SBC boards of old and creating Asterisk appliances with them. If you've got a little asterisk box running on some embedded looking hardware somewhere, it doesn't matter whose name is on the sticker, its got some Kielhofner in it.

I live about a mile from Star2Star. I ought to pop in one of these days and see what they're up to.

Post reply on HN