Bug kills Intel gig-E controllers Star2Star CTO Kristian Kielhofner has identified a buggy implementation the Intel 82574L Ethernet controller that makes some kit subject to a “packet of death” that hangs the port receiving the packet. His lengthy description of the discovery of the bug is at his personal blog, here, but it boils down to this: with the right …
The guy has shown how 'clever' he is by tracking down a really tough bug. Kudos to him, but now, a rare bug wich affected one handset and one switch has been published in a way that every 10 year old l33t is going to try to exploit, just to see if they are 'clever' too. Relly dumb.
This post has been deleted by its author
... now we need to learn about this thing they call "fuzzing".
Hopefully they will now understand the usefulness of throwing "crazy data" at all their hardware/software interfaces, just to see if it really is bullet proof. Isn't this the fundamental that MS also figured out _eventually_?
I have a whole raft of kit with 82574L - I use it on my home server and my home lab. I have yet to see anything resembling that bug. The offset in question is in the data portion of the packet so assuming semi-random packet distribution we are looking at multiple crashes a day under heavy load. I do not see that.
Further to this - 82574L is one of the most popular cards going into mid-range desktop kit from HP, Dell, etc. A bug like that would have made these unusable. I suspect that this is limited to specific BIOSes and specific VLANs. Intel cards have a feature (no, it is not a bug) where one VLAN is reserved for out of band management (1000-something, forgot the number). Traffic on that VLAN is interpreted and can be used for lights out management if the machine supports it. If the card is misconfigured so that the default VLAN instead of 1000+ is treated as management you can see all kinds of wierd stuff (including resetting the machine). The more interesting part is why is he seeing is with Asterisk because Linux immediately disables that rather insane feature on boot.
"with the right combination of SIP traffic, the hex value 32 (ASCII 2) with the offset 0x47f would crash the interface that received it."
Well, actually, the right combination of *any* traffic, but yes, the SIP traffic triggered it.
What complicates matters is that he found out another value "inoculated" the card against crashes so that probably is why it is so hard to track down. Also not all cards appear vulnerable - different firmware versions etc?
Icon: ignore description, look at image ;)
We uploaded the offending packet to our online packet viewer, CloudShark, with some notes on what to look for and links to Kristian's articles on the topic. Check it out here:
http://appliance.cloudshark.org/news/cloudshark-in-the-wild/intel-packet-of-death-capture/
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
