cURL är ett mjukvaruprojekt som består av ett bibliotek och en kommandotolk som syftar till filöverföring.
Daniel Stenberg (författare till cURL-projektet) nyligen meddelat genom ett blogginlägg, information om en sårbarhet som upptäcktes i verktyget för att ta emot och skicka data över nätverket curl och libcurl-biblioteket.
Det nämns att sårbarheten (redan katalogiserad under CVE-2023-38545) beror på en bugg i värdnamnsupplösningskoden innan du kommer åt SOCKS5-proxyn.
SOCKS5 är ett proxyprotokoll. Det är ett ganska enkelt protokoll för att sätta upp nätverkskommunikation genom en dedikerad "mäklare". Protokollet används till exempel vanligtvis när man ställer upp kommunikation genom Tor, men också för att komma åt Internet från organisationer och företag.
SOCKS5 har två olika värdnamnsupplösningslägen. Antingen löser klienten värdnamnet lokalt och skickar destinationen som en löst adress, eller så skickar klienten det fullständigt kvalificerade värdnamnet till proxyn och tillåter proxyn att lösa värden på distans.
Som sådant misslyckande kan orsaka buffertspill och potentiellt exekvera en angripares klientkod vid åtkomst till en HTTPS-server som kontrolleras av angriparen via verktyget curl eller ett program som använder libcurl. men problemet endast närvarande om åtkomst via en SOCKS5 proxy är aktiverat i curl. Vid direkt åtkomst utan proxy visas inte sårbarheten.
Ägaren av en webbplats som nås av curl via en SOCKS5-proxy beskrivs som att kunna:
Utlösa ett buffertspill på klientsidan genom att returnera en omdirigeringskod för begäran (HTTP 30x) och ställa in "Plats:"-rubriken till en URL med ett värdnamn vars storlek sträcker sig från 16 till 64 KB (16 KB är högsta storlek). för att svämma över den tilldelade bufferten och 65 KB är den högsta tillåtna värdnamnslängden i en URL).
Om omdirigering av begäran är aktiverad i libcurl-konfigurationen och SOCKS5-proxyn som används är tillräckligt långsam, kommer det långa värdnamnet att skrivas till en liten buffert, uppenbarligen av mindre storlek.
I sitt blogginlägg, Daniel Stenberg nämnde att sårbarheten förblev oupptäckt i 1315 XNUMX dagar. Den säger också att 41% av de tidigare identifierade sårbarheterna i curl förmodligen hade kunnat undvikas om curl hade skrivits på ett minnessäkert språk, men det finns inga planer på att skriva om curl på ett annat språk inom överskådlig framtid.
Sårbarheten påverkar främst libcurl-baserade applikationer och visas i curl-verktyget endast när du använder alternativet "–limit-rate" med ett värde mindre än 65541, eftersom libcurl tilldelar en 16 KB buffert som standard och 100 KB i curl, men denna storlek ändras beroende på värdet på " –limit-rate” parameter.
Det nämns att om värdnamnet är upp till 256 tecken skickar curl omedelbart namnet till SOCKS5-proxyn för upplösning, och om namnet är mer än 255 tecken växlar den till den lokala resolvern och skickar den redan definierade adressen till SOCKS5 . På grund av en bugg i koden kan flaggan som indikerar behovet av lokal upplösning sättas till ett felaktigt värde under långsam förhandling av en anslutning över SOCKS5, vilket leder till att ett långt värdnamn skrivs till en buffert som tilldelas med förväntan att lagra IP:n adress eller namn, inte överstiga 255 tecken.
Slutligen nämns det sårbarheten åtgärdades i curl version 8.4.0 och som åtgärder för att förbättra säkerheten för kodbasen, föreslås det att utöka verktygen för att testa koden och mer aktivt använda beroenden skrivna på programmeringsspråk som garanterar säker drift med minne. Man överväger också att gradvis ersätta delar av curl med alternativ skrivna på säkra språk, till exempel den experimentella Hyper HTTP-backend implementerad i Rust.
Om du är det intresserad av att veta mer om detkan du kontrollera detaljerna I följande länk.