Intel Ethernet controller vulnerable to 'packet of death'

Intel Ethernet controller vulnerable to 'packet of death'

Summary: Sending a specially crafted packet to an Intel 82574L Ethernet controller can cause the hardware to hang, and the 'packet of death' could be put to malicious use and crash systems even when protected by a firewall.

TOPICS: Intel, Networking
(Credit: Intel)

A bug discovered in Intel's 82574L Ethernet controller leaves equipment vulnerable to attack via a so-called "packet of death."

Star2Star's chief technology officer Kristian Kielhofner identified the root of the bug, after customers began reporting that their Star2Star-branded hardware was experiencing random crashes. This put the company on the trail of the bug, which eventually lead to Intel's Ethernet controller.

"The system and Ethernet interfaces would appear fine," writes Kielhofner, "and then after a random amount of traffic the interface would report a hardware error (lost communication with PHY) and lose link. Literally the link lights on the switch and interface would go out. It was dead."

Kielhofner explains what he means by "dead."

"Nothing but a power cycle would bring it back. Attempting to reload the kernel module or reboot the machine would result in a PCI scan error. The interface was dead until the machine was physically powered down and powered back on. In many cases, for our customers, this meant a truck roll." ('Truck roll' is slang for needing a technician to visit the scene to fix the problem.)

After a lot of packet captures, Star2Star traced the problem to a particular VoIP manufacturer, and after further lengthy debugging the responsible packet was identified.

"Problem packets had just the right Call-ID, tags, and branches to cause the '2' in the ptime to line up with 0x47f."

So far, the problem appeared to be isolated and confined to a particular vendor—except that it isn't. Kielhofner's team was able to create packets and target them at particular systems.

"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!"

Kielhofner has posted a test page that allows system admins to test to see if their equipment is vulnerable. But  be careful that you don't end up needing a truck roll.

Kielhofner's team has been working with Intel on a fix for this bug, but as yet it is unclear how widespread the problem is or how other Intel hardware is affected.

UPDATE: An Intel spokesperson says that this is "one case scenario isolated to one specific motherboard maker and  incorrect implementation of the controller on their motherboard (incorrect EEPROM image was programmed during manufacturing)." More details as soon as I get them.

Topics: Intel, Networking

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • How do I find out if I have one of these chips?

    Someone must have a list of affected machines.
    • Check you OS system infor

      Most of the time you can check your drivers in control panel or do a system information listing.
      IF your using that chip it should list it. Intel also had these chips on LAN cards sold through all kinds of vendors. You would most likely have to look on the LAN card board to see if it has that chip.
    • determine chip set

      If you are in windows, the listing for the device in the hardware manager will tell you what chip set you have.

      In linux, there's a number of different ways, lspci, lshw or whatever the distribution's graphical interface for viewing hardware should do the trick.
  • The next big thing

    I definitely see attacks being more tailored and targeted towards things like hardware, OS, apps and users. Such as the attacks on the NY times, WSJ and the Federal reserve. Its not about wide spread damage, its about gathering information. Sure, eventually we will see a wide spread attack but that's child's play and does nothing to help those who carry out these attacks. They want information or they get paid by someone or some government or business for information. Not to terrorize users.
  • I was wondering... long it would be before we started finding flaws in low level hardware/firmware like this. All that cheap outsourcing has a price after all. My wife's company is finding out the same the hard way.

    I'm still waiting for the hackers to find flaws in the base TCP/IP protocol. Then we'd all be shafted.
  • Were other devices tested?

    I wonder if other controllers were tested.
    For instance, like my Intel 82579LM
  • "So far, the problem appeared to be isolated and confined to a particular..

    vendor" - care to share which vendor?
    • Ummm

      "except that it isn't."
    • That vendor

      would probably be Intel, if they're saying it's an Intel network controller with the issue. My question is if it's drivers or the physical hardware itself.
  • Irresponsible

    You really have to wonder at the benefit of publishing this information. You might as well start advertising those homes that you pass that you notice have open windows, or, doors ajar. Totally irresponsible action by those announcing and those publishing it.
    • as if anyone interested

      can not walk down the street and see for themselves
  • Ping of death Redux?

    I remember the 'Ping of Death' on HP-UX 9.04....
  • Ethernet controller

    The price of using software controlled interfaces etc. Hardware controlled would not be as vunerable.
    • Tell that to Samsung.

      They had to patch the Android kernel to cover a security problem with their Exynos SoC.
    • and you know it because

      ... you just know it, right?
  • 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: