Treiber für Netzwerkkarten verraten Informationen

Durch die fehlende Initialisierung von Puffern in Treibern für Ethernetkarten werden Daten aus altem Netzwerkverkehr mitgesendet. Über die fehlerhaften Treiber berichteten die Sicherheitsexperten von @stake bereits Anfang des Jahres. Daraufhin erschien eine Liste verwundbarer Treiber auf CERT/CC. Jetzt hat sich herausgestellt, dass auch einige Treiber, etwa von VIA und AMD, unter Windows 2003 betroffen sind.

IP-Pakete werden zum Transport über Ethernet in einen Ethernetframe eingekapselt, das heißt, das Paket erhält einen Ethernet-Header und eine weitere Checksumme. Ist die Summe aller Bytes kleiner als die erforderlich Mindestlänge 46, zum Beispiel bei ICMP-Pakten, wird das Datenfeld aufgefüllt, in dem auch das IP-Paket liegt. Die Länge des IP-Paketes bleibt davon unberührt. Der eigentliche Fehler der Treiber resultiert nun aus der Herkunft der Füllbytes.

Um einen Datenframe zu übertragen, muss er in den Sendepuffer kopiert werden. Hierzu wird ein Zeiger auf den zu kopierenden Puffer und eine Variable mit der Länge des Puffers übergeben. Ist der Datenframe nun wie beschrieben zu kurz, wird nur die Variable angepasst, die die Länge enthält. Der ursprüngliche Frame bleibt davon unberührt. RFC 1042 fordert an dieser Stelle eigentlich das Auffüllen mit "Octets of Zero", also Null-Bytes. In der Folge werden nun aber Bytes über den Originalpuffer hinaus gelesen, die interessante Daten enthalten können.

Je nach Netzwerktreiber variiert die Lage des Puffers im Speicher. Drei mögliche Orte kommen in Frage: Kernel Memory, statisch allozierter Treiberspeicher oder Hardwarepuffer auf der Karte selbst. Im Hardwarepuffer ist jedes Füllbyte Artefakt eines zuvor gesendeten Frames. Der Treiberspeicher ist zwar etwas größer, allerdings auch immer mit Daten aus älteren Paketen gefüllt. Im Kernel Memory hat man die geringsten Chancen, sinnvolle Daten zu treffen, dazu ist der Speicher in der Regel zu groß.

Eine Variante dieses Fehlers offenbarte der DSL-Router OfficeConnect 812 von 3Com: Pakete zur Beantwortung von DHCP-Request wurden in den Puffer eines vorhergehenden HTTP-Requests geschrieben, ohne diesen vorher zu löschen. In der Folge wurde dann Fragmente daraus mitgesendet. (dab)