Deep-Dive: Auffinden und Beheben kritischer Schwachstellen in libcurl/curl

Vor Kurzem wurden die Sicherheits- und Entwickler-Communitys durch einen Sicherheitshinweis des curl-Projektleiters Daniel Stenberg alarmiert. Er teilte die beunruhigende Nachricht mit, dass eine neue, am 11. Oktober veröffentlichte curl-Version zwei kritische Sicherheitslücken schließt, von denen er eine als „wahrscheinlich die schlimmste curl-Sicherheitslücke seit langer Zeit“ bezeichnet.

Ein Post-Mortem-Bericht in Stenbergs Blog stellte fest, dass betroffene Versionen der curl-Bibliothek anfällig für einen Heap-basierten Pufferüberlauf sind, der auf ein seit 2002 bestehendes Problem mit dem SOCKS5-Proxy-Protokoll zurückzuführen ist.

Da curl bereits seit 1998 als Befehlszeilen-Tool im Einsatz ist, gilt es weithin als ein Grundpfeiler des Internets. Aufgrund dieser langen Geschichte und der weiten Verbreitung könnte eine Schwachstelle in dieser Abhängigkeit dauerhafte Auswirkungen auf die allgemeine Cybersicherheit haben.

Dieser Vorfall ähnelt dem verheerenden Log4Shell-Angriff auf Log4j, eine weitere anfällige Abhängigkeit, die auch fast zwei Jahre später noch ausgenutzt wird.
‍
>>> Testen Sie Ihr Wissen jetzt mit unserer curl-Mission!‍

Die Schwachstelle: Pufferüberlauf

Der Exploit wird unter CVE-2023-38545 geführt und betrifft die curl-Versionen 7.69.0 bis einschließlich 8.3.0. Der Hauptfehler ist ein Heap-basierter Pufferüberlauf. Erste Berichte deuteten darauf hin, dass eine erfolgreiche Ausnutzung zu einem schwerwiegenderen Angriff zur Remotecodeausführung (RCE) führen könnte. Obwohl dies für einen Angreifer ein möglicher Weg ist, handelt es sich um einen seltenen Anwendungsfall.

Ein mildernder Umstand ist, dass die schädliche Kommunikation über einen SOCKS5-Proxy erfolgen muss, was eine relativ seltene Konfiguration darstellt.

Werfen wir zum Vergleich mit dem curl-Exploit einen Blick auf diese Erklärung zum Pufferüberlauf:

Wenn curl angewiesen wird, einen SOCKS5-Proxy zu verwenden, leitet es den Hostnamen weiter, damit der Proxy ihn auflöst. Wenn der Hostname jedoch das Limit von 255 Bytes überschreitet, löst curl den Hostnamen lokal auf (wie im Code-Schnipsel unten zu sehen: Quelle).

Bei einem langsamen Handshake zwischen Client und Proxy kann es vorkommen, dass der lange Hostname in den Speicherpuffer kopiert wird, anstatt der (kürzeren) aufgelösten Adresse. Der zugewiesene Speicherbereich erlaubt nur einen Wert von 255 Bytes. Erhält er einen Wert, der dieses Limit überschreitet, überschreiben die Daten die Grenzen des Speicherpuffers.

>>> Probieren Sie es selbst aus in dieser interaktiven Mission!

Ein Pufferüberlauf ist ein mächtiger Angriffsvektor, der in vielen älteren Programmiersprachen häufig vorkommen kann. In diesem speziellen Fall ermöglichte die Ausnutzung in manchen Kontexten einen schwerwiegenderen Angriff in Form von RCE, obwohl dieser Pfad selten und unwahrscheinlich bleibt.

Wie können Sie das Risiko eines Pufferüberlaufs mindern?

Die wichtigste Maßnahme ist derzeit das Einspielen der Patches für alle anfälligen Instanzen. Denken Sie daran, dass curl so weit verbreitet ist, dass es nicht immer offensichtlich ist, ob Komponenten Ihres Systems diese Abhängigkeit nutzen. In diesem Fall sind eine Überprüfung und anschließende Patching-Maßnahmen erforderlich.

Generell lassen sich Pufferüberläufe durch die Verwendung einer speichersicheren Sprache wie Rust vermeiden. Bei einem so umfangreichen Projekt wie curl ist es jedoch nicht praktikabel, das gesamte System kurzfristig auf eine andere Sprache umzustellen oder neu zu schreiben. Wie Stenberg anmerkt, während er über die Möglichkeit diskutiert, mehr Abhängigkeiten in speichersicheren Sprachen zu nutzen oder Teile von curl schrittweise zu ersetzen: „... die Entwicklung verläuft derzeit in fast gletscherartigem Tempo und zeigt mit schmerzlicher Deutlichkeit die damit verbundenen Herausforderungen. curl wird auf absehbare Zeit in C geschrieben bleiben.“ Es ist eine gewaltige Aufgabe mit immensen Auswirkungen auf die Sicherheit.

Sicherheitsfehler passieren und werden auch weiterhin passieren. Man kann sich nicht immer darauf verlassen, dass Scanner und Tests jeden möglichen Angriffsvektor erkennen. Unsere größte Waffe im Kampf gegen diese Fehler ist daher ein kontinuierliches Sicherheitsbewusstsein und der stetige Ausbau unserer Fähigkeiten.
‍

Möchten Sie mehr darüber erfahren, wie Sie sicheren Code schreiben und Risiken minimieren können?

Probieren Sie unsere Heap-Overflow-Challenge kostenlos aus.

Wenn Sie an weiteren kostenlosen Programmierrichtlinien interessiert sind, schauen Sie sich den Secure Code Coach an, der Ihnen hilft, bei den Best Practices für sicheres Programmieren auf dem Laufenden zu bleiben.