CVE-2023-38545 is een nieuwe vulnerability in cURL waarvan de details op 11 oktober 2023 openbaar worden gemaakt. Deze vulnerability wordt omschreven als "the worst security problem found in curl in a long time".

In deze blogpost vertellen we je wat we al weten en houden we je op de hoogte van de nieuwste ontwikkelingen.

12 oktober 2023

Zoals gisteren in de loop van de dag steeds duidelijker werd is deze vulnerability een stuk minder hoog ingeschaald dan aanvankelijk gedacht. De uiteindelijke inschaling is medium/medium.

We realiseren ons dat dit het nadeel is van "vroegtijdig informeren" en door te varen op de beperkte informatie welke op dat moment voor handen is. "Better safe than sorry"... zeggen we dan maar.

Ondanks de beperkte inschaling wil dit niet zeggen dat deze vulnerability volledig genegeerd mag worden. cURL/libcurl zijn nog steeds vulnerable voor deze aanval en er zijn al diverse publieke POC's gemaakt om deze vulnerability uit-te-buiten. Zoals de eerder genoemde POC en deze: https://github.com/UTsweetyfish/CVE-2023-38545(externe link)

Nogmaals, cURL is alleen vulnerable indien:

  • Een applicatie welke cURL (libcurl) gebruikt geen CURLOPT_BUFFERSIZE instelt.
  • Wanneer "CURLOPT_BUFFERSIZE" wel ingesteld wordt, maar dan met een zeer kleine waarde (<66 kB / 65541 bytes)
  • cURL zet deze "CURLOPT_BUFFERSIZE" standaard op 100kB. Dit is dus niet vulnerable mits er door de gebruiker rate limiting wordt ingesteld waardoor de effectieve buffer dus ook weer kleiner is dan 66 kB.

Indien dit het geval is dan is deze vulnerability alleen exploitable als:

  • De aanvaller een cURL request naar een malicious server (onder hun beheer) weet te sturen met een hostnaam welke groter is dan de buffer.
  • cURL moet voor deze request een proxy server (SOCKS5) gebruiken (proxy-resolver mode)
  • cURL moet ingesteld zijn om redirects te volgen (automatisch)
  • De SOCKS5 handshake tussen cURL en de SOCKS5 server moet "langzaam genoeg" zijn om deze local variable bug (waar de overflow zich in bevindt) te triggeren. Hoe langzaam dit exact moet zijn is niet bekent. Men vermoed echter dat de "normale server latency" langzaam genoeg is (en dus kunnen we aannamen dat aan deze requirement standaard voldaan wordt)

Vanwege al deze requirements, moderne memoryprotections en door het feit dat aanvallers eerst een aanvalsoppervlak moeten vinden dat cURL op een kwetsbare manier blootlegt is de reden voor het uiteindelijke medium/medium advies.

Hieronder een lijst met "known suplliers" welke cURL gebruiken in hun software:
https://curl.se/docs/companies.html(externe link)

Deze kwetsbaarheid vormt nog altijd een groot probleem voor bepaalde (verouderde) security devices en devices welke "untrusted" inhoud ophalen met behulp van cURL onder de motorkap. cURL is vaak ook beschikbaar op de meeste Linux-besturingssystemen. Deze vulnerability kan hier dus ook als een nieuwe "privilege escalation" methode gebruikt worden (mits de aanvalsketen dit toelaat).

Omdat deze vulnerability ondertussen lager is ingeschaald en de belangrijkste zaken ondertussen bekend zijn (en hier terug te lezen zijn) sluiten we deze liveblog.

Mochten er nog zeer belangrijke feiten aan het licht komen dan openen we deze liveblog opnieuw.

11 oktober 2023

Update 12:16:

Om vulnerable te zijn moet er aan 4 voorwaarden voldaan worden:

  1. Er moet een request verstuurd worden v.a. een vulnerable curl-client. Deze request moet gerouteerd worden via een SOCKS5 proxy.
  2. De negotiation buffer van de machine moet kleiner zijn dan 65541 bytes.
  3. De "hello reply" van de SOCKS5 proxy is langzaam genoeg.
  4. De aanvaller heeft een hostname ingesteld die groter is dan de negotiation buffer.

==================================================

*** Dit is een "early advisory". Dit betekend dat we deze gemaakt hebben om u zo snel mogelijk op de hoogte te brengen van de meest recente informatie. Sommige details kunnen later aangepast / gewijzigd worden. ***

Deze vulnerability bevindt zich in cURL en is een "CWE-122: Heap-based Buffer Overflow".

De vulnerability bevindt zich in het hostname gedeelte wanneer een SOCKS5 proxy gebruikt wordt en cURL dus feitelijk het "verkeer" (URL) afgeeft aan de SOCKS proxy middels een SOCKS5 proxy handshake.

Wanneer cURL wordt gevraagd om de hostnaam door te geven aan de SOCKS5-proxy (zodat het adres kan worden ge-resolved want dit doet cURL zelf niet), is de maximale lengte die de hostnaam kan zijn 255 bytes.

Als wordt gedetecteerd dat de hostnaam langer is dan 255 bytes dan resolved cURL de naam lokaal. Daarna geeft cURL het resolved adres door aan de proxy. Als gevolg van een bug wanneer een langzame SOCK5-proxy gebruikt wordt kan de lokale variabele welke deze setting beinvloed (lokaal afhandelen of door de proxy) beinvloed worden met als gevolg dat de unresloved name welke dan langer is dan 255 bytes in de target-buffer (heap-based download buffer in libcurl) geplaatst wordt. Dit resulteerd vervolgens in een "Heap-based Buffer Overflow".

Om een overflow te laten plaatsvinden, is een SOCKS5-handshake nodig die langzaam genoeg is om de "local variable bug" te activeren. Daarnaast moet de client een hostnaam gebruiken die langer is dan de downloadbuffer. Normale "server latency" is waarschijnlijk "langzaam" genoeg om deze bug te activeren zonder dat een aanvaller deze hoeft te beïnvloeden door DoS- of SOCKS-server control.

Een overflow is alleen mogelijk binnen applicaties welke niet de CURLOPT_BUFFERSIZE specificeren of deze kleiner dan 65541 bytes specificeren. cURL zet de CURLOPT_BUFFERSIZE standaard op 100kB en is dus niet vulnerable behalve als rate-limiting ervoor zorgt dat de snelheid langzamer is dan 65541 bytes/second.

De vulnerable versies zijn:
libcurl 7.69.0 t/m 8.3.0

Niet vulnerable zijn de volgende versies:
libcurl < 7.69.0 en >= 8.4.0

Het is aan te raden om cURL zo spoedig mogelijk te patchen naar versie 8.4.0.

Is dit niet mogelijk zorg er dan voor dat:

  • CURLPROXY_SOCKS5_HOSTNAME proxies met cURL niet gebruikt worden
  • Stel geen proxy environment variabele in naar: socks5h://

POC: https://gist.github.com/xen0bit/0dccb11605abbeb6021963e2b1a811d3(externe link)

< 11 oktober 2023 (vooraankondiging)

De details m.b.t. CVE-2023-38545 (samen met CVE-2023-38546) zijn nog niet bekend maar naar verwachting zal deze vulnerability veel impact hebben. Daarom heeft het CERT-WM besloten hier een blogpost van te maken. In deze post houden we jullie op de hoogte van de nieuwste ontwikkelingen en referenties.

Dit is wat er wel weten:

  • CVE-2023-38545
  • De vulnerability bevindt zich in cURL en LibCurl.
  • cURL bestaat al 25 jaar en bestaat uit een library (libcurl) en een command-line tool (curl). cURL wordt gebruikt voor het versturen van data over het netwerk middels verschillende protocollen (HTTP(S), FTP, SMB, Telnet etc.).
  • cURL wordt gebruikt in meer dan 10 biljoen software pakketten waaronder operating systems, mobiele telefoons, dockerfiles, IoT en OT devices.
  • Morgen komt versie 8.4 uit waarin de vulnerability gepatched is. Het globale advies zal dan ook zijn om met spoed te patchen.
  • Het is momenteel onbekend of de vulnerability al misbruikt wordt.
  • Diverse bronnen uiten de verwachting dat het exploiten van deze vulnerability pas mogelijk is indien er aan specifieke voorwaarden voldaan wordt en dat niet iedere instance vulnerable is doordat niet aan deze voorwaarden voldaan wordt. Dit is echter speculatie!

Het advies voor nu is om te inventariseren welke software gebruik maakt van cURL en LibCurl. Het is hierbij opportuun om te beschikken over een up-to-date Software Bill of Materials (SBOM) of specifieke tooling actief welke het software-landschap kan scannen op specifieke modules zoals deze. Het advies is dan eveneens om alvast de juiste queries te maken zodat vroegtijdig inzichtelijk wordt om welke pakketten het gaat en waar deze software gelokaliseerd is.

Zodra we meer informatie hebben zullen we deze met jullie delen middels een update op deze post.