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 …
Smart or Dumb?
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.
Re: Smart or Dumb?
Considering how old this bug sounds maybe now Intel will be shamed into fixing it. After reading the guys blog and some comments posted there by insiders Intel really comes off looking like incompetent asshats.
Re: Smart or Dumb?
> you'll need to be on the same ethernet segment... No routers or VLAN aware switches should be in the mix
Denial of service on a *really* small scale.
So there is an off switch for the Internet
We got the hosing perfected...
... 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_?
There is something fishy here
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.
I have THREE Gigabyte boards (MA78's) with dead ethernet ports when booted with WINDOWS 7, that work perfectly with LINUX (and with old 10/100 boards fitted)
They all worked perfectly BEFORE a windows update a couple of years ago, but even a fresh reinstall wont get them to work now.
"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 ;)
Packet Capture of the Offending Packet
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:
- Analysis iPhone 6: The final straw for Android makers eaten alive by the data parasite?
- First Crack Man buys iPHONE 6 and DROPS IT to SMASH on PURPOSE
- First Fondle Reg journo battles Sydney iPHONE queue, FONDLES BIG 'UN
- TOR users become FBI's No.1 hacking target after legal power grab
- Vid Reg bloke zips through an iPHONE 6 queue from ZERO to 60 SECONDS