Zum Hauptinhalt Zur Navigation

Security: EEPROM-Fehler verursacht "Intel Packet of Death"

Ein als "Intel Packet of Death" bezeichnetes Paket führt zum Absturz einiger Server mit einem Netzwerkchip von Intel. Daran soll ein fehlerhaftes EEPROM schuld sein. Der Netzwerkchip sei in Ordnung, schreibt Intel.
/ Jörg Thoma
1 Kommentare News folgen (öffnet im neuen Fenster)
Ein fehlerhaftes EEPROM eines einzigen Herstellers verursacht einen Fehler im Netzwerkcontroller 82574L von Intel. (Bild: Intel)
Ein fehlerhaftes EEPROM eines einzigen Herstellers verursacht einen Fehler im Netzwerkcontroller 82574L von Intel. Bild: Intel

Mit einem einzigen Netzwerkpaket konnte ein VoIP-Telefonserver zum Absturz gebracht werden. Der Entdecker des Fehlers(öffnet im neuen Fenster) taufte das Paket "Intel Packet of Death", da es reproduzierbar nur auf einem Netzwerkchip von Intel zum Absturz führte. Intel hat nun Entwarnung gegeben. Nicht der Chip selbst sei von dem Fehler betroffen, sondern ein kaputtes EEPROM, das lediglich ein einziger Mainboardhersteller verwendet. Der Fehler kann demnach durch ein Bios-Update behoben werden.

Bei dem betroffenen Netzwerkcontroller handelt es sich um den 82574L Gigabit Ethernet Controller von Intel(öffnet im neuen Fenster) , der auf Mainboards verbaut wird, die in erster Linie in Servern zum Einsatz kommen. Intel verschweigt in seiner Mitteilung(öffnet im neuen Fenster) , welcher Hersteller das fehlerhafte EEPROM nutzt. Der Entdecker des Todespakets(öffnet im neuen Fenster) Kristian Kielhofner teilte jedoch mit, dass es sich um den taiwanischen Hersteller Lex Computech handelt.

Kielhofers Unternehmen Star2Star(öffnet im neuen Fenster) nutzt das Mainboard in seinen VoIP-Servern, die Asterisk einsetzen. Er habe bereits ein neues Firmware-Image ausprobiert und der Fehler sei inzwischen behoben, sagte er The Verge(öffnet im neuen Fenster) .

Das Paket sei von nur einem einzigen VoIP-Telefon der Marke Yealink SIP-T22P an den Server gesendet worden. Der Netzwerkcontroller stürzte dabei vollständig ab und ließ sich auch nach einem kompletten Neustart nicht mehr nutzen. Erst nachdem der Server kurzzeitig vom Stromnetz genommen worden war, konnte er wieder verwendet werden.

Bislang war Kielhofer der Einzige, der den Fehler reproduzieren konnte. Da der Fehler derart spezifisch war, konnte Kielhofer ihn erst nach 150 Mannstunden dingfest machen.


Relevante Themen