Zusammenfassung

  • RFC 3128 verband Tiny-Fragment- und Überlappungsangriffe, sodass Filter und Zielhost unterschiedliche TCP-Header aus derselben Fragmentfolge ableiten konnten.
  • Die Abhilfe verlangte im Fragment mit Offset null den vollständigen minimalen TCP-Header und behielt die Sperre für Offset eins bei.
  • Der Effekt hing von Regelwerk und Reassemblierungsverhalten ab; passierte Fragmente bewiesen weder eine fertige Verbindung noch einen kompromittierten Dienst oder einen Fehler aller Implementierungen.

Eine Firewall kann nur über die Bytes entscheiden, die sie vor sich hat. RFC 3128 fragte, was geschieht, wenn diese Bytes später nicht mehr dieselben sind.

Im Beispiel beginnt das erste IPv4-Fragment bei Offset null und enthält mindestens sechzehn Bytes des TCP-Headers. Der Zielport bezeichnet einen Dienst, der eingehende Verbindungen annehmen darf. Portangaben und Kontrollfelder ergeben zusammen einen zulässigen Verbindungsbeginn. Der Filter lässt das Fragment passieren.

Das zweite Fragment beginnt ebenfalls bei null, endet aber nach acht Transportbytes. Es wiederholt Quellport, Zielport und Sequenznummer, ohne die späteren TCP-Flags zu enthalten. In dieser kurzen Version kann der Absender den Zielport auf einen Dienst ändern, der nur ausgehende Verbindungen führen soll. Ein drittes Fragment vervollständigt das Datagramm.

Bevorzugt der Zielstack beim Überlapp die kurze Ersatzfolge, entsteht ein gemischter Header. Der Port stammt aus dem zweiten Fragment, die späteren Kontrollbits aus dem ersten. Der Filter prüfte eine zulässige Kombination; TCP kann eine Kombination erhalten, die der Filter nie als Ganzes gesehen hat.

Der Angriff setzte an einer früheren Gegenmaßnahme an. RFC 1858 hatte Tiny Fragments und überlappende Fragmente getrennt behandelt. Tiny Fragments verschieben entscheidende Transportfelder aus dem ersten Stück. Überlappungen nutzen aus, dass Reassembler bei mehrfach gelieferten Bytes unterschiedliche Fassungen wählen können. Die sogenannte Indirect Method verwarf TCP-Fragmente mit Fragment Offset eins.

Da IPv4 den Offset in Acht-Byte-Einheiten zählt, beginnt Offset eins unmittelbar nach den ersten acht TCP-Bytes. Seine Sperre verhinderte ein bekanntes Muster, bei dem die Kontrollbits in das nächste Fragment ausgelagert wurden. Die Maßnahme war nicht unvernünftig; sie war nur auf eine einzelne Form der Trennung zugeschnitten.

RFC 3128 verschob den Ersatz zurück auf Offset null. Damit umging die Folge nicht die Regel durch einen verborgenen Offset, sondern durch eine zweite Version derselben frühen Bytes. Die Sperre von Offset eins garantierte noch nicht, dass jedes Offset-null-Fragment lang genug war, um die Grundlage einer Entscheidung unveränderlich zu machen.

Das Dokument legte damit eine verteilte Kontrollfläche offen. Der Sender bestimmt Grenzen, Reihenfolge und Überlapp. Der Filter kontrolliert die Zulassung seiner sichtbaren Fassung. Der IP-Stack des Ziels bestimmt die Reassemblierung. TCP entscheidet über den fertigen Abschnitt, der Dienst über den weiteren Effekt. Keine dieser Instanzen besitzt allein die ganze Beweiskette.

RFC 3128 formulierte deshalb bedingt. Der Ausgang hänge von der genauen Reassemblierungsimplementierung des Ziels ab. RFC 791 hatte Fragmentfelder und Wiederzusammensetzung eingeführt; RFC 815 zeigte eine praktische Verarbeitung von Lücken und Überlappungen. Eine universelle Regel, welches mehrfach gelieferte Byte auf allen Geräten gewinnen musste, ergab sich daraus jedoch nicht.

Diese Abhängigkeit verbietet die Behauptung, jeder Host sei verwundbar gewesen. Sie verbietet aber auch die Annahme der Firewall, der Host werde ihre Sicht teilen. Wer Fragmente ohne Normalisierung oder vollständige Reassemblierung weitergibt, überlässt die endgültige Auswahl einem anderen Programm.

Die Korrektur war ein Längeninvariant. Ist das Protokoll TCP, der Offset null und der Transportteil kürzer als ein vollständiger minimaler Header, wird das Paket verworfen. Offset eins bleibt ebenfalls gesperrt. Eine Port- und Flag-basierte Richtlinie darf erst entscheiden, wenn ihr gesamter minimaler Feldsatz im Anfangsfragment vorliegt.

Diese Regel schließt den kurzen Ersatz des Beispiels. Sie schafft nicht jede IPv4-Mehrdeutigkeit ab, schreibt nicht jeder Firewall vollständige Reassemblierung vor und beweist keine Implementierungsverbreitung. Ebenso wenig beweist die Zulassung einen TCP-Handshake, einen lauschenden Dienst oder eine Anwendungswirkung.

Spätere RFCs zogen in einzelnen Bereichen strengere Grenzen. RFC 5722 verlangte bei IPv6 das Verwerfen des gesamten Datagramms, sobald Fragmente überlappen. RFC 7112 forderte die vollständige Headerkette im ersten IPv6-Fragment. RFC 6274 bewertete IPv4-Sicherheitsrisiken erneut, und RFC 8900 beschrieb Fragmentierung als betrieblich fragil, wenn Endpunkte und Middleboxes nicht dasselbe Verhalten besitzen.

Diese späteren Regeln sind kein Nachweis für ein bestimmtes Produkt im Jahr 2001. Sie bewahren die architektonische Aussage: Durchsetzung und Verbrauch müssen sich auf dasselbe Objekt beziehen. Andernfalls kann eine lokale Prüfung formal korrekt sein und dennoch eine andere endgültige Nachricht autorisieren.

Die Struktur findet sich auch bei URL-Normalisierung, mehrfacher Dekodierung und verschiedenem Zusammenführen doppelter Felder. Das sind andere Protokolle und Schwachstellen. Gemeinsam ist ihnen, dass entscheidungsrelevante Information nach der Zulassung noch verändert werden kann.

Historisch wichtig ist daher auch die Beweisgrenze. Ein Firewall-Log beweist, welchen temporären Header die Firewall sah. Es beweist nicht automatisch, welchen Port TCP erhielt, ob eine Verbindung zustande kam oder ein Dienst Schaden nahm. Für diese Aussagen braucht es die ursprünglichen Fragmente, die tatsächliche Reassemblierungsregel und die folgenden Protokollzustände.

Quellen