An den wenigen Posts der letzten Wochen läßt sich leicht erahnen, daß ich bis über beide Ohren in Arbeit stecke - aber die Schlagzeile "deadly TCP denial-of-service attack - TCP broken beyond repair?" hat mich dann doch aufhorchen lassen. Die Entwicker des Portscanners Unicornscan sind auf (mehrere?) neue Angriffsvektoren auf TCP gestoßen; Details wollen sie auf der T2-Konferenz Mitte Oktober 2008 in Helsinki vorstellen, einige grobe Informationen konnte man diesem Podcast-Interview entnehmen (Seite sicher bald ge-slashdot-tet, hier die Episode im Coral Cache; das englischsprachige Interview beginnt bei 5:50 Minuten und dauert ca. 35 Minuten).
In dem Interview berichten die Entwickler, daß sie auf das Problem durch Zufall gestoßen sind: Bei der Entwicklung eines möglichst schnellen Portscanners haben sie den TCP-Stack (zumindest zu Teilen) nachimplementiert. Um möglichst viele Verbindungen schnell testen zu können, haben sie analoge Problem zu einem Server, der mit vielen Verbindungen gleichzeitig umgehen muß: Es müssen sich die Zustände der jeweiligen Verbindung gemerkt und eingehende Pakete diesen Zuständen zugeordnet werden. Hierzu bedient sich Unicornscan desselben Tricks, mit dem sich Server vor SYN-Flood-Angriffen schützen: Diese codieren eine Authentisierungs-Information in der Antwort auf ein SYN-Paket (hier weitere Details über SYN-Cookies); Unicornscan benutzt ein "inverses SYN-Cookie", die Zustandsinformationen für den Verbindungsaufbau werden ebenfalls in der TCP sequence number codiert. Nun ist das Programm in der Lage, ein passendes ACK-Paket zum endgültigen Aufbau der Verbindung zu schicken, ohne selbst größere Mengen an Ressourcen zu verbrauchen. Der Server hingegen erhält das ACK-Paket und allokiert die nötigen Ressourcen für die vermeintlich erfolgreich aufgebaute Verbindung. Das Ergebnis hiervon ist ein Denial-of-Service ähnlich dem 1985 publizierten SYN-Flooding; der einzige Unterschied zum Angriff von damals ist, daß die Absenderadresse korrekt sein muß (der Angreifer muß ja auch das passende ACK-Paket generieren).
Auf dem Server werden mehrere Ressourcen in Anspruch genommen: Zunächst wird Speicher für die Zustandsdaten der geöffneten Verbindung allokiert. Die meisten Betriebssysteme besitzen eine harte Obergrenze für die maximale Anzahl offener TCP-Verbindungen. Zusätzlich wird eine Timer-Resource benötigt, um Pakete ohne Bestätigung erneut zu übertragen. Laut dem Interview genügt eine geringe Bandbreite (genannt wurden 10 Pakete pro Sekunde), um einen Server so zu stressen, daß er keine weiteren TCP-Verbindungen mehr annimmt.
Im Gespräch wurden Angriffsvarianten mit unterschiedlichen Auswirkungen angesprochen - in wie weit diese auf Implementierungsfehler einzelner Systeme oder prinzipielle Protokollschwächen zurückzuführen sind, wird sich nach der vollständigen Publikation zeigen. Erwähnt wurden Geräte, welche in einem Bestimmten Zustand des TCP-Handshakes ein Paket ohne Abbruch wieder und wieder übertrugen. Andere Systeme froren komplett ein oder booteten neu (ich vermute, daß es sich hier um ein Problem mit den ausgehenden Timer-Ressourcen o.ä. handelt).
Alles in allem sehen die Entwickler keinen "easy fix" für die Misere. Allerdings sind sie zuversichtlich, daß die Internet Community eine Lösung finden wird: Schließlich sind über 90% des E-Mail-Verkehrs Spam, und trotzdem ist E-Mail als Medium ungebrochen populär und verwendet nach wie vor das alte SMTP.
Aufgrund der genannten technischen Umstände lindert möglicherweise eine Ratenlimitierung das Problem. Wegen des inverse-SYN-Cookies kann der Angreifer zwar mühelos beliebig viele Verbindungen initiieren, jedoch muß er eine korrekte Absenderadresse angeben. Unter Linux könnte man beispielsweise (zusätzlich zum SYN-Cookie-Schutz) mit Hilfe von iptables die Anzahl an Verbindungen pro IP und pro Zeiteinheit limitieren. Damit würde zumindest ein gewisser Schutz gegen einzelne Angreifer gewährleistet - eine Lösung des Problems wäre dies allerdings noch nicht.
Bleibt also abzuwarten, was in der Veröffentlichung an weiteren technischen Details zu lesen sein wird. Die Idee mit den inversen SYN-Cookies ist jedenfalls cool - ich bin gespannt.
(via Slashdot)