Manipulierte Zeitstempel in TCP-Paketen bringen Verbindungen zum Stillstand

Sendet ein Angreifer TCP-Pakete mit sehr großen Timestamps und der richtigen Sequenznummern an einen Host, so kann er damit die Timer einer bestehenden Verbindung zu einem anderem Host neu setzen.

In Pocket speichern vorlesen Druckansicht 54 Kommentare lesen
Lesezeit: 2 Min.
Von
  • Daniel Bachfeld

Das US-CERT weist in einer Vulnerability Note auf eine Schwachstelle in der Implementierung der TCP/IP-Stacks einiger Hersteller hin, mit der Angreifer TCP-Verbindungen anderer Rechner stören oder zum Stillstand bringen können. Ursache des Problems ist die fehlerhafte Verarbeitung von zu großen Zeitstempeln bei Einsatz von TCP-Timestamps und PAWS (Protection Against Wrapped Sequence Numbers). Beide Techniken dienen zur Erhöhung der Übertragungsleistung in Netzwerken und greifen auf interne Timer zurück, um festzustellen, ob ein Paket bereits veraltet ist oder doppelt gesendet wurde.

Sendet ein Angreifer TCP-Pakete mit sehr großen Timestamps und der richtigen Sequenznummern an einen Host, so kann er damit die Timer einer bestehenden Verbindung zu einem anderem Host neu setzen. Dies veranlasst den angegriffenen Rechner unter Umständen die Pakete der eigentlichen Verbindung als zu alt einzustufen und zu verwerfen. In der Folge bleibt die Verbindung stehen. Für eine erfolgreiche DoS-Attacke ist allerdings die Kenntnis sowohl der Quell- und Zieladresse als auch der verwendeten Ports der kommunizierenden Systeme notwendig.

Das US-CERT weist explizit darauf hin, dass es bei einigen TCP/IP-Implementierungen nicht erforderlich ist, eine korrekte Sequenznummer zum Einschleusen eines Paketes zu erraten. Dort wird der Timer bereits vor dem Prüfen der Sequenznummer neu gesetzt. Im Anhang der Note des CERT findet sich eine Liste möglicher betroffener Hersteller. Bislang wurde die Schwachstelle in Produkten von Cisco, Hitachi, OpenBSD, FreeBSD und Microsoft bestätigt. Microsoft hat das Problem bereits mit MS05-019 gelöst. Cisco hat ein eigenes Advisory veröffentlicht. OpenBSD hat den Fehler in der kommenden Version 3.7 gefixt, für Version 3.6 steht ein Patch bereit. FreeBSD hat laut US-CERT noch keine Informationen zur Lösung geliefert.

Update
FreeBSD hat die Fehler bereits am 10. April im CURRENT-Entwicklungszweig und am 19. April im RELENG_5-Zweig beseitigt. Warum das US-CERT darüber nicht informiert wurde, konnte man gegenüber heise Security bislang allerdings noch nicht begründen.

Siehe dazu auch: (dab)