Vertiefung: Auffinden und Beheben hochgradig gefährlicher libcurl/curl-Schwachstellen

Erst vor kurzem wurden die Sicherheits- und Entwicklergemeinschaften durch eine Mitteilung des leitenden Entwicklers des curl-Projekts, Daniel Stenberg, darauf aufmerksam gemacht , dass eine neue Version von curl - die am 11. Oktober veröffentlicht wurde - zwei schwerwiegende Sicherheitslücken behebt, von denen er eine als "wahrscheinlich die schlimmste curl-Sicherheitslücke seit langem" bezeichnet.

In einem Postmortem in Stenbergs Blog wird darauf hingewiesen, dass die betroffenen Versionen der curl-Bibliothek für einen Heap-basierten Pufferüberlauf anfällig sind, der mit einem alten Problem im Zusammenhang mit dem seit 2002 verwendeten SOCKS5-Proxy-Protokoll steht.

Mit seiner Verwendung als Befehlszeilentool, die bis ins Jahr 1998 zurückreicht, wird curl weithin als Grundpfeiler des Internets angesehen. Mit einer so langen Geschichte und weitverbreiteten Nutzung ist es eine Abhängigkeit, die, wenn sie anfällig ist, anhaltende Auswirkungen auf die allgemeine Cybersicherheit haben könnte.

Dieser Vorfall weist Ähnlichkeiten mit dem verheerenden Log4Shell-Angriff in Log4j auf, einer weiteren verwundbaren Abhängigkeit, die fast zwei Jahre später immer noch ausgenutzt wird.
‍
>>> Testen Sie jetzt Ihr Wissen mit unserer curl-Mission!‍

Die Sicherheitslücke: Pufferüberlauf

Die Schwachstelle ist unter CVE-2023-38545 aufgeführt und betrifft die Curl-Versionen 7.69.0 bis einschließlich 8.3.0. Bei dem primären Fehler handelt es sich um eine Heap-basierte Pufferüberlauf-Schwachstelle. Ersten Berichten zufolge könnte eine erfolgreiche Ausnutzung zu einem noch verheerenderen Angriff mit Remote-Code-Ausführung (RCE) führen. Dies ist zwar ein möglicher Arbeitsablauf für einen Bedrohungsakteur, aber eher ein seltener Anwendungsfall als eine Selbstverständlichkeit.

Die einzige Rettung, um einige der Risiken zu mindern, ist vielleicht, dass die bösartige Kommunikation über einen SOCKS5-Proxy laufen muss, was eine relativ seltene Anwendung ist.

Vergleichbar mit dem Curl-Exploit, werfen wir einen Blick auf diesen Buffer Overflow-Explainer:

Wenn curl angewiesen wird, einen SOCKS5-Proxy zu verwenden, wird der Hostname weitergegeben und vom Proxy aufgelöst. Wenn der Hostname jedoch die 255-Byte-Grenze überschreitet, löst curl den Hostnamen lokal auf (wie im folgenden Codeschnipsel zu sehen: Quelle).

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

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

Pufferüberlauf ist ein mächtiger Angriffsvektor, der in vielen älteren Programmiersprachen vorkommt. In diesem speziellen Fall machte die Ausnutzung den Weg frei für einen ernsteren und schädlicheren Angriff in Form von RCE in einigen Kontexten, obwohl dieser Weg ungewöhnlich und unwahrscheinlich bleibt.

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

In diesem Stadium besteht die höchste Priorität darin, die Patches auf alle anfälligen Instanzen anzuwenden, wobei darauf hinzuweisen ist, dass die Verwendung von curl so weit verbreitet ist, dass es nicht unbedingt offensichtlich ist oder angekündigt wird, dass Komponenten Ihres Systems die verwendete Abhängigkeit enthalten. In diesem Fall sind Überprüfungen und anschließende Patches erforderlich. 

Im Allgemeinen können Pufferüberlauf-Fehler durch die Verwendung einer speichersicheren Sprache wie Rust entschärft werden, jedoch ist es bei einem ausufernden Projekt wie curl nicht praktikabel, es auf eine andere Sprache zu portieren oder es aus einer Laune heraus umzuschreiben. Wie Stenberg bemerkt, während er das Potenzial diskutiert, mehr Abhängigkeiten zu nutzen und zu unterstützen, die in speichersicheren Sprachen geschrieben sind - oder die Alternative, Teile von curl nach und nach zu ersetzen - "... die Entwicklung geschieht ... derzeit in einer fast eisigen Geschwindigkeit und zeigt mit schmerzlicher Klarheit die damit verbundenen Herausforderungen. curl wird für die absehbare Zukunft in C geschrieben bleiben." Es 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 darauf zu verlassen, dass Scanner und Tests jeden möglichen Angriffsvektor aufspüren. Daher ist unsere größte Waffe im Kampf gegen diese Bugs das Engagement für ein kontinuierliches Sicherheitsbewusstsein und den Aufbau von Fähigkeiten.
‍

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

Probieren Sie unsere Heap Overflow Herausforderung kostenlos.

Wenn Sie an weiteren kostenlosen Codierungsrichtlinien interessiert sind, besuchen Sie Sicherer Code Coach damit Sie immer auf dem neuesten Stand der besten Praktiken für die sichere Programmierung sind.