Deep-Dive: Libcurl/curl-Schwachstellen mit hohem Schweregrad finden und beheben

Erst vor Kurzem wurden die Sicherheits- und Entwicklungsbehörden mit einem Hinweis der curl-Projektder Hauptentwickler, Daniel Stenberg, der hat das unglückliche Schreiben fallen lassen dass eine neue Version von Curl — veröffentlicht am 11. Oktober — veröffentlicht wurde, um zwei schwerwiegende Sicherheitslücken zu beheben, von denen er eine als „wahrscheinlich die schlimmste Curl-Sicherheitslücke seit langem“ beschreibt.

EIN postmortem In Stenbergs Blog wurde darauf hingewiesen, dass die betroffenen Versionen der Curl-Bibliothek anfällig für eine HEAP-basierte Pufferüberlauf-Sicherheitslücke sind, die auf ein Legacy-Problem mit dem seit 2002 verwendeten SOCKS5-Proxyprotokoll zurückzuführen ist.

Mit seiner Verwendung als Befehlszeilentool, das bis ins Jahr 1998 zurückreicht, wird Curl weithin als eine grundlegende Säule des Internets angesehen. Aufgrund seiner langen Geschichte und seiner weit verbreiteten Nutzung handelt es sich um eine Abhängigkeit, die, wenn sie sich als anfällig herausstellt, anhaltende Auswirkungen auf die allgemeine Cybersicherheit haben könnte.

Dieser Vorfall weist Ähnlichkeiten mit dem verheerenden Log4Shell-Angriff in Log4J, eine weitere anfällige Abhängigkeit, die fast zwei Jahre später immer noch ausgenutzt wird.
‍
>>> Testen Sie jetzt Ihr Wissen mit unserer Curl-Mission!‍

Die Sicherheitslücke: Buffer Overflow

Der Exploit ist detailliert unter CVE-2023-38545und wirkt sich auf die Curl-Versionen 7.69.0 bis einschließlich 8.3.0 aus. Der Hauptfehler ist eine Heap-basierte Buffer Overflow-Schwachstelle. Erste Berichte deuten darauf hin, dass eine erfolgreiche Ausnutzung zu einem verheerenderen Remote Code Execution (RCE) -Angriff führen könnte. Dies ist zwar ein möglicher Arbeitsablauf für einen Bedrohungsakteur, aber eher ein seltener Anwendungsfall als eine Tatsache.

Vielleicht besteht die einzige Rettung, um einige der Risiken zu mindern, darin, dass die böswillige Kommunikation über einen SOCKS5-Proxy geleitet werden muss, was eine relativ ungewöhnliche Bereitstellung ist.

Vergleichbar mit dem Curl-Exploit, schauen wir uns diesen Buffer Overflow-Erklärer an:

Wenn curl angewiesen wird, einen SOCKS5-Proxy zu verwenden, gibt es den Hostnamen weiter und lässt ihn vom Proxy auflösen. Wenn der Hostname jedoch die Grenze von 255 Byte überschreitet, löst curl den Hostnamen lokal auf (wie im folgenden Codeausschnitt zu sehen ist): Quelle).

Falls es einen langsamen Handshake zwischen dem Client und dem Proxy gibt, ist es möglich, dass der lange Hostname anstelle der (kürzeren) aufgelösten Adresse in den Speicherpuffer kopiert wird. Der zugewiesene Speicherbereich erlaubt nur einen 255-Byte-Wert. Wenn er also einen Wert empfängt, der diese Grenze überschreitet, überschreiten die Daten die Grenzen des Speicherpuffers.

>>> Probiere es hier selbst aus spielbare Mission!

Buffer Overflow ist ein mächtiger Angriffsvektor, der in vielen älteren Programmiersprachen weit verbreitet sein kann. In diesem speziellen Fall machte die Ausnutzung in einigen Kontexten einem schwerwiegenderen und schädlicheren Angriff in Form von RCE Platz, obwohl dieser Weg nach wie vor ungewöhnlich und unwahrscheinlich ist.

Wie können Sie das Pufferüberlaufrisiko mindern?

In dieser Phase besteht die höchste Priorität darin, die Patches auf alle anfälligen Instanzen anzuwenden. Wir möchten Sie daran erinnern, dass die Verwendung von Curl so weit verbreitet ist, dass es möglicherweise nicht unbedingt offensichtlich oder angekündigt ist, dass Komponenten Ihres Systems die verwendete Abhängigkeit enthalten. In diesem Fall sind Prüfungen und anschließendes Patchen erforderlich.

Im Allgemeinen können Pufferüberlauffehler durch die Verwendung einer speichersicheren Sprache wie Rost, wie es bei einem weitläufigen Projekt wie curl der Fall ist, ist es jedoch nicht praktikabel, in eine andere Sprache zu portieren oder aus einer Laune heraus neu zu schreiben. Wie Stenberg Anmerkungen bei der Diskussion über die Möglichkeit, mehr Abhängigkeiten zu verwenden und zu unterstützen, die in speichersicheren Sprachen geschrieben sind — oder die Alternative, Teile von Curl schrittweise stückweise zu ersetzen — „... die Entwicklung läuft... derzeit fast mit eiserner Geschwindigkeit ab und zeigt mit schmerzhafter Klarheit die damit verbundenen Herausforderungen. Curl wird auf absehbare Zeit in C geschrieben bleiben.“ Das ist kein kleines Unterfangen, und die Auswirkungen auf die Sicherheit sind immens.

Sicherheitsfehler können und werden passieren, und es ist nicht immer möglich, sich auf Scanner und Tests zu verlassen, um jeden möglichen Angriffsvektor zu erkennen. Daher ist unsere größte Waffe im Kampf gegen diese Bugs die Verpflichtung, kontinuierlich Sicherheitsbewusstsein zu entwickeln und entsprechende Fähigkeiten zu entwickeln.
‍

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

Testen Sie unsere Heap Overflow Challenge kostenlos.

Wenn du an weiteren kostenlosen Codierungsrichtlinien interessiert bist, schau dir das an Sicherer Code-Coach um Ihnen zu helfen, den Überblick über die Best Practices für sichere Codierung zu behalten.