cURL is een softwareproject bestaande uit een bibliotheek en een commando-interpreter gericht op bestandsoverdracht.
Daniel Stenberg (auteur van het cURL-project) onlangs aangekondigd via een blogpost, informatie over een kwetsbaarheid die is gedetecteerd in het hulpprogramma om gegevens via het netwerk te ontvangen en te verzenden curl en de libcurl-bibliotheek.
Er wordt vermeld dat de kwetsbaarheid (reeds gecatalogiseerd onder CVE-2023-38545) is te wijten aan een bug in de resolutiecode van de hostnaam voordat u toegang krijgt tot de SOCKS5-proxy.
SOCKS5 is een proxyprotocol. Het is een vrij eenvoudig protocol voor het opzetten van netwerkcommunicatie via een speciale "makelaar". Het protocol wordt bijvoorbeeld veelal gebruikt bij het opzetten van communicatie via Tor, maar ook om toegang te krijgen tot internet vanuit organisaties en bedrijven.
SOCKS5 heeft twee verschillende hostnaamresolutiemodi. Ofwel zet de client de hostnaam lokaal om en geeft de bestemming door als een opgelost adres, ofwel geeft de client de volledig gekwalificeerde hostnaam door aan de proxy en staat de proxy toe de host op afstand om te zetten.
Als zodanig de mislukking kan een bufferoverloop veroorzaken en mogelijk het uitvoeren van de code aan de clientzijde van een aanvaller bij toegang tot een HTTPS-server die door de aanvaller wordt beheerd via het curl-hulpprogramma of een toepassing die libcurl gebruikt. maar het probleem alleen aanwezig bij toegang via een SOCKS5-proxy is ingeschakeld in krul. Bij rechtstreekse toegang zonder proxy treedt de kwetsbaarheid niet op.
Van de eigenaar van een site waartoe curl toegang krijgt via een SOCKS5-proxy wordt beschreven dat hij in staat is om:
Activeer een bufferoverflow aan de clientzijde door een verzoekomleidingscode (HTTP 30x) te retourneren en de header 'Locatie:' in te stellen op een URL met een hostnaam waarvan de grootte varieert van 16 tot 64 KB (16 KB is de maximale grootte). om de toegewezen buffer te laten overstromen en 65 KB is de maximaal toegestane lengte van de hostnaam in een URL).
Als verzoekomleiding is ingeschakeld in de libcurl-configuratie en de gebruikte SOCKS5-proxy langzaam genoeg is, wordt de lange hostnaam naar een kleine buffer geschreven, uiteraard van kleinere omvang.
In zijn blogpost, Daniel Stenberg zei dat de kwetsbaarheid 1315 dagen onopgemerkt bleef. Er staat ook dat 41% van de eerder geïdentificeerde kwetsbaarheden in curl waarschijnlijk voorkomen hadden kunnen worden als curl in een geheugenveilige taal was geschreven, maar er zijn geen plannen om curl in de nabije toekomst in een andere taal te herschrijven.
Het beveiligingslek treft vooral op libcurl gebaseerde applicaties en verschijnt alleen in het curl-hulpprogramma bij gebruik van de “–limit-rate” optie met een waarde kleiner dan 65541, aangezien libcurl standaard een buffer van 16 KB toewijst en 100 KB in curl, maar deze grootte verandert afhankelijk van de waarde van de “ –limit-rate”-parameter.
Er wordt vermeld dat als de hostnaam maximaal 256 tekens lang is, Curl de naam onmiddellijk doorgeeft aan de SOCKS5-proxy voor resolutie, en als de naam meer dan 255 tekens bevat, schakelt deze over naar de lokale resolutie en geeft het reeds gedefinieerde adres door aan SOCKS5 . Als gevolg van een bug in de code kan de vlag die de noodzaak van lokale resolutie aangeeft, worden ingesteld op een onjuiste waarde tijdens langzame onderhandeling van een verbinding via SOCKS5, wat ertoe leidt dat een lange hostnaam wordt geschreven naar een toegewezen buffer met de verwachting dat het IP-adres wordt opgeslagen adres of naam, niet langer dan 255 tekens.
Ten slotte wordt dat vermeld de kwetsbaarheid is opgelost in curl versie 8.4.0 en als maatregelen om de beveiliging van de codebasis te verbeteren, wordt voorgesteld om de tools voor het testen van de code uit te breiden en actiever gebruik te maken van afhankelijkheden geschreven in programmeertalen die een veilige werking met geheugen garanderen. Het overweegt ook om delen van curl geleidelijk te vervangen door opties die in veilige talen zijn geschreven, zoals de experimentele Hyper HTTP-backend geïmplementeerd in Rust.
Wanneer je geïnteresseerd om er meer over te weten, kunt u de details bekijken In de volgende link.