Curl Bug Hype Fizzles Efter Patching Reveal

Curl Bug Hype Fizzles Efter Patching Reveal

Curl Bug Hype Fizzles After Patching Reveal PlatoBlockchain Data Intelligence. Vertical Search. Ai.

I flere dage har cybersikkerhedssamfundet ventet spændt på den store afsløring om to sikkerhedsfejl, der ifølge curl-grundlæggeren Daniel Stenberg inkluderede en, der sandsynligvis var "den værste krøllesikkerhedsfejl i lang tid."

Curl er et open source proxy-opløsningsværktøj, der bruges som en "mellemmand" til at overføre filer mellem forskellige protokoller, som er til stede i bogstaveligt talt milliarder af applikationstilfælde. Forslaget om en massiv åben kildekode-biblioteksfejl fremkaldte minder om den katastrofale log4j fejl fra 2021. Som Alex Ilgayev, chef for sikkerhedsforskning hos Cycode, bekymrede sig, "kan sårbarheden i curl-biblioteket vise sig at være mere udfordrende end Log4j-hændelsen for to år siden."

Men efter dagens afsløring af patches og fejldetaljer, ingen af ​​sårbarhederne levede op til hypen.

Påvirker et begrænset antal krølleimplementeringer

Den første vuln, en heap-baseret bufferoverløbsfejl sporet under CVE-2023-38545, blev tildelt en vurdering på "høj" på grund af potentialet for datakorruption eller endda fjernudførelse af kode (RCE). Spørgsmålet ligger i SOCKS5 proxy-overdragelsen, ifølge rådgiveren.

"Når curl bliver bedt om at videregive værtsnavnet til SOCKS5-proxyen for at tillade det at løse adressen i stedet for at det bliver gjort af curl selv, er den maksimale længde, som værtsnavnet kan være 255 bytes," sagde rådgiveren. "Hvis værtsnavnet detekteres til at være længere end 255 bytes, skifter curl til lokal navneløsning og videregiver i stedet kun den løste adresse til proxyen."

Fejlen kunne tillade, at den forkerte værdi afleveres under SOCKS5-håndtrykket.

"På grund af en fejl kan den lokale variabel, der betyder 'lad værten løse navnet', få den forkerte værdi under et langsomt SOCKS5-håndtryk, og i modsætning til hensigten, kopier det for lange værtsnavn til målbufferen i stedet for kun at kopiere løst adresse der,” tilføjede rådgiveren.

Den høje strenghedsbetegnelse gælder dog kun for en brøkdel af implementeringer, siger cybersikkerhedsekspert Jake Williams.

"Dette er kun høj sværhedsgrad under meget begrænsede omstændigheder," siger Williams. ”Jeg tror, ​​det er bare et problem, at når man har en sårbarhed på et bibliotek, så ved man, hvordan biblioteket bliver brugt. Du skal tildele CVE'en under forudsætning af et worst case-scenarie for implementering."

Den anden curl-fejl, sporet under CVE-2023-38546, er en lav-sværhedsgrad cookie-indsprøjtningsfejl, der kun påvirker libcurl-biblioteket, ikke krøllen i sig selv.

"Jeg tror, ​​at dette er et større problem for sikkerhedsenheder og apparater (som henter upålideligt indhold og ofte bruger krøller under hætten)," sagde Andy Hornegold i en erklæring som reaktion på udgivelsen af ​​krøllefejlsdetaljerne. "Jeg kan ikke se, at det er et stort problem for selvstændig brug."

Farerne ved at hype en rettelse

Ud over halsbrand for cybersikkerhedsteams, kan hypning af en løsning, før tekniske detaljer frigives, give en nem sejr til trusselsaktører. I dette tilfælde påpeger Williams, at RedHat opdaterede sin ændringslog forud for den officielle curl-udgivelse, som kunne have givet cyberangribere vigtig information om uoprettede mål, hvis sårbarheden havde været så farlig som tidligere antaget.

Faktisk så Mike McGuire med Synopsys farerne ved den øgede opmærksomhed på krølleopdateringen og skrev om det i en blog den 9. oktober.

"På trods af at de ikke har yderligere detaljer om sårbarheden, vil trusselsaktører uden tvivl begynde at udnytte forsøg," skrev McGuire. "Derudover er det ikke uhørt for angribere at poste falske 'faste' versioner af et projekt fyldt med malware for at drage fordel af teams, der forsøger at patche sårbar software."

Tidsstempel:

Mere fra Mørk læsning