Ich hatte gestern noch über den Fable- und Mythos-Bann der US-Regierung berichtet und kaum war die Tinte trocken, taucht eine Geschichte auf, die das Ganze mit einer gewissen Ironie abrundet.
Denn genau das Modell, das Washington gerade vom Netz genommen hatte, war kurz zuvor damit beschäftigt, einen fast 30 Jahre alten Sicherheitsfehler in einer der meistgenutzten Proxy-Software der Welt aufzuspüren.
Veröffentlicht mit Augenzwinkern auf calif.io – Meet Squidbleed.
Was ist Squid überhaupt?
Squid ist ein weit verbreiteter Web-Proxy, der vor allem in Unternehmensnetzen, Schulen und überall dort zu finden ist, wo Traffic gefiltert, gecacht oder überwacht werden soll. Wer schon mal im Büro oder im WLAN eines Flughafens saß und gemerkt hat, dass bestimmte Seiten gesperrt sind – da steckt oft Squid dahinter. Das Ding ist eine Institution.
Und wie das bei Institutionen manchmal so ist: Unter der gepflegten Oberfläche schlummert manchmal Code, der noch aus einer anderen Zeit stammt.
Der Bug: Eine Zeitreise nach 1997
Der Kern von Squidbleed liegt in Squids FTP-Parser – ja, FTP, dem Protokoll, das die meisten modernen Browser schon vor Jahren aus ihrem Repertoire gestrichen haben. Squid unterstützt FTP aber nach wie vor standardmäßig.
Das Problem: FTP hat kein standardisiertes maschinenlesbares Format für Dateilistungen. Jeder Server liefert das irgendwie als Textblock, und Squid muss diesen Wirrwarr parsen. Ein Commit vom 18. Januar 1997 (Für die jüngeren Leser: das ist älter als Google!) hat damals eine Sonderbehandlung für NetWare-FTP-Server eingebaut, die zwischen Zeitstempel und Dateiname vier statt einem Leerzeichen setzen.
Der Fix damals: Eine Schleife, die Whitespace überspringt, bis der Dateiname beginnt.
Das Problem dabei: strchr() eine C-Standardbibliotheksfunktion gibt auch dann einen Treffer zurück, wenn man nach dem Nullterminator \0 sucht. Das heißt: Wenn nach dem Zeitstempel gar kein Dateiname folgt, läuft der Pointer einfach weiter über das Ende des Buffers hinaus. Und weiter. Und weiter. Bis er auf Daten trifft, die nicht mehr zum FTP-Listing gehören.
Was dann passiert, ist das namensgebende Problem: Der Proxy liest fremde Heap-Daten und schickt sie dem Angreifer als vermeintlichen Dateinamen zurück.
Zu komplex? Geht auch einfacher:
Okay, stellt euch vor, ihr seid Bibliothekar in einer riesigen Bücherei. Eure Aufgabe ist es, euren Besuchern Bücher zu besorgen. Jemand kommt rein und sagt: „Hol mir bitte das Buch aus Regal 7!“ Ihr geht nun also hin, holt es, fertig. Das ist Squid: Ein Mittelsmann, der Dinge für andere holt.
Der Zettelkasten
In dieser Bücherei gibt es auch einen alten Zettelkasten für FTP-Server. FTP ist so ein uraltes System zum Dateien-Übertragen. Stellt es euch vor wie einen sehr, sehr alten Aktenschrank aus den 80ern, den eigentlich niemand mehr benutzt, der aber noch in der Ecke steht weil ihn keiner weggeräumt hat. Wenn jemand fragt „was liegt denn alles in diesem Aktenschrank?“, geht Squid hin, liest die Beschriftungen der Mappen vor und schreibt sie auf einen Zettel.
Das Problem mit dem Zettel
Jetzt kommt der Fehler. Squid liest die Beschriftung einer Mappe, zum Beispiel „Datum: 16. Januar, Dateiname: …“ und sucht dann nach dem Dateinamen. Dabei benutzt es einen kleinen Helfer namens strchr, der sagt: „Geh so lange weiter, bis du etwas findest, das kein Leerzeichen ist.“
Aber was passiert, wenn nach dem Datum gar kein Dateiname steht? Normaler Menschenverstand sagt: „Dann hör auf zu suchen.“ strchr denkt das aber nicht so. Der sucht einfach weiter. Über den Zettel hinaus. Über die Mappe hinaus. Über den Aktenschrank hinaus. Er liest einfach weiter, was auch immer daneben liegt.
Was liegt daneben?
In der Bücherei-Analogie: daneben liegen die Zettel anderer Besucher. Zettel auf denen steht: „Benutzer Max hat sich heute mit Passwort XY eingeloggt“ oder „Benutzer Lisa hat gerade ihre Kreditkartennummer eingegeben.“ Squid liest all das aus, weil strchr nicht aufgehört hat zu suchen und schickt es dann brav als „Dateiname“ zurück an denjenigen, der gefragt hat.
Was kann ein Angreifer damit bekommen?
Squid recycelt intern Speicherpuffer. Ein 4KB-Puffer, der gerade noch die HTTP-Anfrage eines anderen Nutzers desselben Proxys enthielt, kann kurz danach für das FTP-Listing wiederverwendet werden ohne dass der alte Inhalt gelöscht wird. Der Overread liest dann genau diese Reste aus und sendet sie zum Angreifer.
Im Klartext: Authorization-Header, Passwörter, API-Keys. Was auch immer andere Nutzer desselben Proxys gerade so durch die Leitung schicken. Upsi.
Die Einschränkungen sind real: Nur unverschlüsseltes HTTP ist betroffen (HTTPS läuft als opaker CONNECT-Tunnel durch den Proxy), und der Angreifer braucht einen FTP-Server, den der Proxy auch tatsächlich erreichen darf. TCP-Port 21 ist aber in Squids Standard-ACL enthalten. Kein Konfigurationsaufwand nötig, solange man irgendwo einen FTP-Server betreiben kann.
Wer hat das gefunden?
Hier kommt der Teil, der mich als jemanden, der gestern noch über den Fable-Bann geschrieben hat, besonders beschäftigt. Das Sicherheitsforschungsteam von Calif.io hat Claude Mythos Preview (also das Modell, das kurz darauf von Washington verboten wurde) bereits im April in den Squid-Quellcode geschickt. Mit der Anweisung, den FTP-State-Machine-Code genauer zu untersuchen.
Das Modell fand den Bug fast sofort und begründete ihn mit Verweis auf den C11-Standard: strchr(w_space, '\0') gibt per Spezifikation einen Non-NULL-Pointer zurück, weil der Nullterminator Teil des Strings ist. Ein Detail, das in fast 30 Jahren Code-Review, Rewrites und Audits offenbar niemandem aufgefallen war.
Der Fix ist übrigens denkbar simpel, zwei zusätzliche Null-Checks vor dem strchr-Aufruf:
- while (strchr(w_space, *copyFrom))
+ while (*copyFrom && strchr(w_space, *copyFrom))Einen Tag Arbeit für die Maintainer. Fast drei Jahrzehnte im Dunkeln.
Was jetzt zu tun ist
Wer Squid betreibt: FTP abschalten, sofern man es nicht aktiv braucht. Chrome hat FTP-Support schon vor Jahren gestrichen, Firefox auch. Wer keinen legitimen FTP-Traffic durch seinen Proxy schickt (vorsichtig vermutet dürften dass 2026 die meisten sein) kann das Feature einfach deaktivieren und die gesamte Angriffsfläche eliminieren.
Addendum : Für alle anderen: Squid 7.6 (veröffentlicht am 8. Juni 2026) und Squid 8 enthalten den Patch bereits (Danke Golem.de für die Meldung). Die offizielle Advisory erschien am 24. Juni. Wer noch auf älteren Versionen sitzt sollte updaten.
Das eigentliche Fazit
Squidbleed ist technisch betrachtet kein weltbewegendes RCE, kein Zero-Click-Wunder. Es ist ein Heap-Overread mit situationalem Impact. Aber es ist symptomatisch für etwas, das in der Open-Source-Welt regelmäßig passiert: Code, der seit Jahrzehnten läuft, von Niemandem mehr wirklich verstanden wird und in dem subtile C-Eigenheiten still vor sich hinrotten.
Dass ausgerechnet ein KI-Modell diesen Bug gefunden hat und zwar das Modell, das die US-Regierung kurz danach als zu gefährlich einstufte hat eine gewisse Qualität. Die Fähigkeit, Sicherheitslücken zu finden, ist offenbar genau das, was Washington beunruhigt hatte. Ob das ein Argument für oder gegen den Bann ist, überlasse ich euch.
Die Antwort liegt irgendwo zwischen den Zeilen von gestern.
FR 
DE 
EN 
ES 
IT