Wie es in curl zu einem Heap-Overflow kam
(daniel.haxx.se)- Mit der Veröffentlichung von curl 8.4.0 wurde CVE-2023-38545 bekannt, ein Heap-Buffer-Overflow bei der Verarbeitung von SOCKS5-Proxys und eine der seltenen curl-Schwachstellen mit dem Schweregrad HIGH
- Das Problem wurde 2020 eingeführt, als der Code für SOCKS5-Verbindungen von einem blockierenden Aufruf auf eine nicht blockierende Zustandsmaschine umgestellt wurde, und betrifft curl seit Version 7.69.0
- Die bisherige Logik, im Modus der Remote-Namensauflösung Hostnamen mit mehr als 255 Byte auf lokale Auflösung umzuschalten, kollidierte mit dem erneuten Aufruf der Zustandsmaschine, sodass ein zu langer Hostname in einen zu kleinen Puffer kopiert werden konnte
- Damit ein Angriff möglich ist, muss ein libcurl-Client den SOCKS5-proxy-resolver-mode und automatische Redirects verwenden, und ein vom Angreifer kontrollierter HTTPS-Server muss ein HTTP-30x-
Location:mit einem Hostnamen von mehr als 16 KB und höchstens 64 KB zurückgeben - Seit curl 8.4.0 wird bei zu langen Hostnamen im Fall der Remote-Auflösung nicht mehr auf lokale Auflösung umgeschaltet, sondern ein Fehler zurückgegeben; außerdem wurde ein Test hinzugefügt, der genau dieses Szenario verhindert
CVE-2023-38545 und curl 8.4.0
- Zusammen mit dem Release von curl 8.4.0 wurden auch die Sicherheitswarnung und Details zu CVE-2023-38545 veröffentlicht
- Das Problem wurde als das schwerwiegendste Sicherheitsproblem seit Langem in curl bewertet und erhielt den Schweregrad HIGH
- Der Kernfehler ist ein Heap-Buffer-Overflow, der unter bestimmten Bedingungen bei der Verarbeitung einer SOCKS5-Proxy-Verbindung auftritt
SOCKS5 und Namensauflösung
- curl unterstützt SOCKS5 seit August 2002
- SOCKS5 ist ein Proxy-Protokoll zum Aufbau von Netzwerkkommunikation über einen zwischengeschalteten Server
- Es kann für die Kommunikation über Tor verwendet werden
- Es kann auch beim Internetzugang innerhalb von Organisationen oder Unternehmen eingesetzt werden
- Bei SOCKS5 gibt es zwei Arten der Hostnamenauflösung
- Der Client löst den Hostnamen lokal auf und übergibt dann die aufgelöste Adresse an den Proxy
- Der Client übergibt den vollständigen Hostnamen an den Proxy, der ihn remote auflöst
Die Änderung von 2020, die die Schwachstelle einführte
- Anfang 2020 wurde die Funktion zum Verbinden mit einem SOCKS5-Proxy von einem blockierenden Aufruf auf eine nicht blockierende Zustandsmaschine umgestellt
- Diese Änderung wurde am 14. Februar 2020 in den Master-Zweig übernommen und in curl 7.69.0 aufgenommen
- curl 7.69.0 war damit sowohl das erste Release mit dieser Verbesserung als auch das erste Release, das anfällig für CVE-2023-38545 war
- Ziel der Änderung war es, spürbar bessere Ergebnisse zu liefern, wenn viele parallele Transfers alle über SOCKS5 laufen
Auflösungsmodus, der in der Zustandsmaschine kaputtging
- Die Funktion der Zustandsmaschine wird wiederholt aufgerufen, sobald weitere Netzwerkdaten eintreffen, bis die Verbindung hergestellt ist
- Die lokale Variable
socks5_resolve_localam Anfang der Funktion gibt an, ob curl den Hostnamen selbst auflösen oder den Namen an den Proxy übergeben soll - Diese Variable wird bei jedem Durchlauf der Zustandsmaschine zu Beginn des Funktionsaufrufs erneut anhand des Proxy-Modus gesetzt
- Die Bedingung im INIT-Zustand verursachte das Problem
- Das Hostnamenfeld von SOCKS5 erlaubt maximal 255 Byte
- Ist ein Hostname länger als 255 Byte, kann der SOCKS5-Proxy ihn nicht auflösen
- Der bisherige curl-Code schaltete im Modus der Remote-Auflösung bei einem zu langen Hostnamen
socks5_resolve_localaufTRUEund wechselte damit in den lokalen Auflösungsmodus
- Wenn der Nutzer Remote-Auflösung angefordert hatte, hätte curl den Modus nicht wechseln dürfen, sondern scheitern müssen, doch dieses vor langer Zeit hinzugefügte Umschaltverhalten blieb bestehen
Wie der Heap-Overflow entsteht
- Wenn der SOCKS5-Server nicht schnell genug ist und die Zustandsmaschine keine weiteren Netzwerkdaten für den nächsten Schritt erhält, kehrt die Funktion zurück
- Sobald später Daten eintreffen, wird dieselbe Zustandsmaschinenfunktion erneut aufgerufen
- Beim erneuten Aufruf wird
socks5_resolve_localam Anfang der Funktion wieder gemäß dem Proxy-Modus gesetzt- Der Wert
TRUE, der beim vorherigen Aufruf wegen des zu langen Hostnamens gesetzt wurde, bleibt nicht erhalten - Stattdessen steht der Wert wieder auf dem Zustand, dass der Proxy den Namen remote auflösen soll
- Der Wert
- curl baut dann den Protokoll-Frame für den Proxy in einem Speicherpuffer auf und kopiert die Zielinformationen hinein
- Durch den falschen Statuswert kann beim Versuch, den zu langen Hostnamen unverändert zu übergeben, über den zugewiesenen Zielpuffer hinaus in benachbarten Heap-Speicher geschrieben werden
Puffergröße und Einschränkungen bei Hostnamen
- curl verwendet beim Aufbau des Protokoll-Frames für den Proxy den allgemeinen Download-Puffer wieder
- Für die Größe dieses Download-Puffers gelten folgende Bedingungen
- Der Standardwert ist 16 KB
- Das curl-Tool setzt die Puffergröße auf 100 KB
- Je nach Anforderung der Anwendung können andere Größen verwendet werden
- Die kleinste zulässige Größe beträgt 1024 Byte
- Ist die Puffergröße kleiner als 65541 Byte, ist dieser Overflow möglich
- Je kleiner der Puffer, desto größer kann der mögliche Overflow ausfallen
- Das Hostnamenfeld einer URL hat praktisch keine Größenbegrenzung, aber der URL-Parser von libcurl lehnt Namen mit mehr als 65535 Byte ab
- DNS erlaubt Hostnamen nur bis maximal 253 Byte
- Legale Namen mit mehr als 253 Byte sind selten, und echte Namen mit mehr als 1024 Byte sind praktisch nicht zu sehen; für einen Angriff ist daher absichtlich ein sehr langer Hostname nötig
- Im Hostnamenfeld einer URL sind nur bestimmte Oktette erlaubt, und ungültige Byte-Werte werden vom URL-Parser verworfen
- Wenn libcurl so gebaut wurde, dass es eine IDN-Bibliothek verwendet, kann auch diese Bibliothek ungültige Hostnamen ablehnen
Bedingungen für einen erfolgreichen Angriff
- Der Angreifer muss einen HTTPS-Server kontrollieren, auf den ein Client mit libcurl über einen SOCKS5-Proxy im proxy-resolver-mode zugreift
- Der bösartige Server muss manipulierte Redirects in Form von HTTP-30x-Antworten zurückgeben können
- Der
Location:-Header des Redirects kann dann einen sehr langen Hostnamen in folgender Form enthaltenLocation: https://aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa/- Die Länge des Hostnamens muss größer als 16 KB und höchstens 64 KB sein
- Wenn im libcurl-Client das automatische Verfolgen von Redirects aktiviert ist und der SOCKS5-Proxy „langsam genug“ ist, um dieses Problem mit der lokalen Variablen auszulösen, wird der manipulierte Hostname in einen zu kleinen Puffer kopiert
- Treffen diese Bedingungen zu, wird in benachbarten Heap-Speicher geschrieben und damit ein Heap-Buffer-Overflow ausgelöst
Fix und Bug Bounty
- Seit curl 8.4.0 wird bei zu langen Hostnamen nicht mehr von Remote-Auflösung auf lokale Auflösung umgeschaltet, sondern ein Fehler zurückgegeben
- Zusätzlich wurde ein eigener Testfall für genau dieses Szenario ergänzt
- Das Problem wurde von Jay Satiro gemeldet, analysiert und gepatcht
- Für diese Schwachstelle wurde die bislang höchste Bug-Bounty in der Geschichte von curl ausgezahlt
- 4.660 US-Dollar an den Melder
- 1.165 US-Dollar an das curl-Projekt gemäß der IBB policy
C und speichersichere Programmiersprachen
- Wäre curl nicht in C, sondern in einer speichersicheren Sprache geschrieben, wäre diese Art von Fehler nicht aufgetreten
- Eine Portierung von curl in eine andere Sprache steht derzeit jedoch nicht zur Debatte
- Realistisch bleiben zwei Ansätze
- Mehr Abhängigkeiten zuzulassen, zu verwenden und zu unterstützen, die in speichersicheren Sprachen geschrieben sind
- curl schrittweise teilweise zu ersetzen, wie bei der Einführung von hyper
- Diese Entwicklung verläuft derzeit sehr langsam, und die damit verbundenen Schwierigkeiten treten klar zutage
- curl wird auch in absehbarer Zukunft in C geschrieben bleiben
- Einschließlich der zwei neuesten in curl 8.4.0 gemeldeten CVEs hätten 41 % der bislang in curl gefundenen Sicherheitslücken möglicherweise verhindert werden können, wenn speichersichere Sprachen verwendet worden wären
- Allerdings war Rust zu der Zeit, als rund 80 % der C-bezogenen Probleme ursprünglich eingeführt wurden, noch keine praktikable Option für diesen Zweck
Ein Fehler, der erst nach 1315 Tagen entdeckt wurde
- Der Fehler blieb 1315 Tage lang im Code
- Mit einem besseren Testsatz hätte er entdeckt werden können
- curl führt wiederholt mehrere statische Code-Analysewerkzeuge aus, aber keines davon fand das Problem in dieser Funktion
- Es ist keine empfehlenswerte Erfahrung, einen Heap-Overflow in Code auszuliefern, der in mehr als 20 Milliarden Installationen steckt
- Der Bericht und der Ablauf bis zur Veröffentlichung lassen sich im HackerOne report nachverfolgen
1 Kommentare
Meinungen auf Hacker News
Es erstaunt mich immer noch, dass so viele Geräte praktisch von einer Library abhängen, die größtenteils von einer einzigen Person geschrieben wurde. Die Last muss enorm gewesen sein, und das zeigt sich auch in der folgenden Aussage:
„Wenn ich den Code jetzt lese, ist es unmöglich, den Bug nicht zu sehen. Es tut wirklich weh, zu akzeptieren, dass ich diesen Fehler nicht bemerkt habe und dass dieser Defekt 1315 Tage lang unentdeckt im Code blieb. Es tut mir leid. Ich bin auch nur ein Mensch.“
Falls Daniel das hier sieht: Danke für deine harte Arbeit, und ich finde, du musst dich überhaupt nicht entschuldigen. Schließlich war der Source öffentlich zugänglich, sodass jeder ihn lesen und prüfen konnte.
https://www.buzzfeed.com/chrisstokelwalker/the-internet-is-b...
„Dieser Bericht sieht völlig korrekt aus, und es tut im Innersten weh.“
Und ebenso im Blog mit „Die Erfahrung, einen Heap-Overflow in Code auszuliefern, der in über zwei Milliarden Installationen steckt, kann ich nicht empfehlen“ – es ist hart, eine so große Verantwortung für so wenig Gegenleistung tragen zu müssen.
Persönlich habe ich oft darüber nachgedacht, wie viel einem entgeht, egal wie sehr man versucht, sich zu konzentrieren. Tätigkeiten wie Code-Reviews scheinen eine gute Methode zu sein, genau diese Aspekte zu trainieren: Aufmerksamkeit oder ein ganzheitliches, kontextuelles Bewusstsein. Zum Beispiel gab es an einem Ort, an dem ich jahrelang häufig vorbeikam, ein schön gepflegtes Blumenbeet. Nachdem ich es zum ersten Mal bemerkt hatte, blieb ich etwa ein Jahr lang immer wieder stehen, um es anzusehen. Vor ein paar Monaten fiel mir dann zum ersten Mal auf, dass nur wenige Fuß daneben ein weiteres, gewissermaßen passendes Blumenbeet existiert. Wahrscheinlich war dieses Beet schon immer dort, aber weil ich nicht einmal wusste, dass es existiert, kann ich es nicht mit Sicherheit sagen.
Wenn man das auf das Wissen der gesamten Menschheit ausweitet, scheint manchmal eine einzige Person etwas zu bemerken, und diese Beobachtung verändert ein Verhalten, das sich dann allmählich unter uns allen verbreitet. Manchmal braucht es mehrere Anläufe und viel Zeit. Ich frage mich auch, wie viele tief hängende Früchte es gibt, die noch niemand bemerkt hat; und ich denke, allein die Integration einfacher, grundlegender Best Practices, die von Menschen etabliert wurden, die bereits aufmerksam hingeschaut haben, könnte die Untergrenze für alle anheben.
Julia Evans’ https://jvns.ca/blog/2023/10/06/new-talk--making-hard-things... und Dan Luus https://danluu.com/p95-skill/ berühren ebenfalls dieses Thema. Unterm Strich empfinde ich große Dankbarkeit gegenüber Stenberg und curl sowie gegenüber den Menschen, die viele Teile der Internet-Infrastruktur geschaffen haben, die wir jeden Tag als selbstverständlich nutzen.
Manchmal wird der Grundsatz „Wenn es nicht kaputt ist, repariere es nicht“ als „Unterstütze es nicht, bis es kaputtgeht“ ausgelegt, was zu ziemlich unangenehmen Überraschungen führt.
Es mag ein Nachhaltigkeitsproblem geben, aber solche Projekte wird es wohl auch in Zukunft geben. Respekt an alle, die wie Daniel nicht nur für sich selbst, sondern für die Community arbeiten.
Die Schlussfolgerung zu Speichersicherheit und speichersicheren Sprachen ist sehr vernünftig. Der Kern ist folgender:
Wäre curl statt in C in einer speichersicheren Sprache geschrieben worden, wäre diese Art von Fehler nicht möglich gewesen.
Ein Ansatz, der in diese Richtung machbar und sinnvoll erscheint, ist, mehr in speichersicheren Sprachen geschriebene Abhängigkeiten zuzulassen, zu nutzen und zu unterstützen und Teile von curl schrittweise Stück für Stück zu ersetzen, wie bei der Einführung von hyper.
Allerdings läuft diese Entwicklung derzeit fast gletscherhaft langsam und macht die damit verbundenen schwierigen Probleme schmerzhaft deutlich. curl wird auf absehbare Zeit in C bleiben. Wem das nicht gefällt, kann selbst die Ärmel hochkrempeln und daran arbeiten.
Einschließlich der beiden neuesten CVEs, die für curl 8.4.0 gemeldet wurden, hätten von der bisherigen Gesamtsumme der in curl gefundenen Sicherheitslücken wahrscheinlich 41 % nicht stattgefunden, wenn eine speichersichere Sprache verwendet worden wäre. Rust war jedoch zu der Zeit, als die ersten etwa 80 % der C-bezogenen Probleme eingebracht wurden, für diesen Zweck keine praktisch nutzbare Option.
Mehrere statische Code-Analyzer wurden wiederholt ausgeführt, aber keiner fand in dieser Funktion irgendein Problem.
Hervorragender Analyseartikel. Allerdings ist selbst nach dem Lesen der CVE noch unklar, in welchen Situationen man betroffen ist. Nach meinem Verständnis ist man betroffen, wenn die folgenden Bedingungen erfüllt sind:
Man nutzt einen SOCKS5-Proxy, lässt den Hostnamen über diesen Proxy auflösen, die Puffergröße wurde vom Standardwert 100 KB auf weniger als 65.541 Byte geändert, und der SOCKS5-Proxy ist zu langsam, um die Anfrage sofort zu verarbeiten.
Korrektur: Die Erklärung zum Puffer ist nicht korrekt. libcurl verwendet den Download-Puffer wieder; der Standardwert liegt bei 16 KB, aber curl selbst setzt ihn offenbar manuell auf 100 KB, sofern man nicht
--limit-rateverwendet. Auch die Bedingung mit der Verzögerung war falsch. Laut CVE ist schon eine normale Serververzögerung wahrscheinlich „langsam“ genug, um diesen Bug auszulösen; ein Angreifer muss also nicht per Denial of Service oder durch Kontrolle des SOCKS-Servers Einfluss nehmen.Daher scheint der Angriffspfad sehr eng zu sein, und ich frage mich, ob ich etwas übersehe.
root@1aac5e228e16:/build/curl-7.74.0# curl -vvv -x socks5h://host.docker.internal:9050 $(python3 -c "print(('A'10000), end='')")Trying 192.168.65.254:9050...* SOCKS5: server resolving disabled for hostnames of length > 255 [actual len=10000]* SOCKS5 connect to AAAAA...* Send failure: Bad file descriptor* Failed to send SOCKS5 connect request.Segmentation faulthttps://gist.github.com/xen0bit/0dccb11605abbeb6021963e2b1a8...
docker-proxygebaut, das über einen Docker-Container mit laufendem openconnect-VPN einen SOCKS5-Tunnel bereitstellt. Das ist nützlich, wenn man mit verschiedenen VPNs mehrerer Kunden zu tun hat und jedes VPN verlangt, den gesamten Traffic der Maschine über sich selbst zu leiten.https://github.com/carlosonunez/docker-proxy
Da es so ausgelegt ist, dass die DNS-Auflösung remote erfolgt, trifft diese CVE hier direkt zu.
Das ist wohl einer der besten CVE-Analyseartikel, die ich bisher gelesen habe. Obwohl der Autor eine der zentralen Softwarekomponenten unserer Zeit geschaffen hat, zeigt er im gesamten Text eine bescheidene Haltung – das muss man einfach loben. Wirklich bewundernswert.
if(!socks5_resolve_local && hostname_len > 255) {socks5_resolve_local = TRUE;}Das ist wirklich eine schlechte Idee. Für Menschen, die Zensurumgehungstools zum Schutz ihrer Privatsphäre nutzen, kann dadurch über DNS die Identität offengelegt werden.
Der Autor sieht das genauso.
https://hackerone.com/reports/2187833
Es heißt zwar: „Wäre curl statt in C in einer speichersicheren Sprache geschrieben, wäre diese Fehlerklasse unmöglich gewesen“, aber höchstens wäre sie vielleicht unmöglich gewesen. Man kann nie sicher wissen, ob es einen Weg gibt, die Barriere der virtuellen Maschine einer Sprache zu verlassen. Allerdings hat der Autor die in RFC1123 festgelegte Längenbegrenzung für DNS-Hostnamen eindeutig ignoriert, und diese Grenze ist auch in Java-Bibliotheken hartcodiert.
https://www.rfc-editor.org/rfc/rfc1123
„Für den Hostnamen in einer URL gibt es keine echte Größenbeschränkung, aber der URL-Parser von libcurl lehnt Namen ab, die länger als 65.535 Byte sind. DNS erlaubt nur Hostnamen mit maximal 253 Byte. Daher sind legale Namen mit mehr als 253 Byte selten. Reale Namen mit mehr als 1.024 Byte hat man praktisch noch nie gesehen.“
DNS wird heute zwar in 99,9 % der Fälle verwendet, ist aber nicht der einzige Mechanismus, um Hostnamen in Adressen aufzulösen.
Ich konnte nicht finden, wo die RFC eine Obergrenze für die Größe von Hostnamen festlegt.
Es kann auch heißen, dass der Compiler zu beweisen versucht, dass Speicher nicht außerhalb seiner Grenzen adressiert wird, nicht ohne eindeutige Ownership adressiert wird und nur innerhalb der Lebensdauer des zugrunde liegenden Objekts adressiert wird. Rust macht das zum Beispiel so.
Natürlich könnte der Compiler an wichtigen Stellen auch interne Fehlerprüfungen und Schutzmechanismen einfügen. Rust macht das nicht, aber in Systemen, in denen man sich um Bitflips in Registern sorgen muss, wäre das hilfreich – etwa in Umgebungen mit hoher Strahlung wie bei Röntgenscannern, wo ECC-Speicher solche Fälle nicht abfängt.
Dafür, dass für eine Ausnutzung sehr spezifische Bedingungen nötig sind, gibt es ziemlich viel Übertreibung und Drama
Das gestern erschienene Sicherheitsupdate für Windows 10 enthielt keine neue curl-Version. Das in Windows enthaltene curl ist weiterhin 8.0.1.
Ein langer und interessanter Artikel, aber man kann ihn auf „Systembibliotheken sollten daher in sicheren Sprachen geschrieben oder auf Korrektheit bewiesen sein“ verkürzen.
Wenn einer der besten, freundlichsten und transparentesten C-Programmierer unserer Zeit so etwas schreibt, sollte man aufmerksam werden.