Curl Bug Hype Fizzles Etter Patching Reveal

Curl Bug Hype Fizzles Etter Patching Reveal

Curl Bug Hype suser etter patching Avslør PlatoBlockchain Data Intelligence. Vertikalt søk. Ai.

I flere dager nå har nettsikkerhetsmiljøet ventet spent på den store avsløringen om to sikkerhetsfeil som ifølge curl-grunnlegger Daniel Stenberg inkluderte en som sannsynligvis var "den verste curl-sikkerhetsfeilen på lenge."

Curl er et åpen kildekode-proxy-oppløsningsverktøy som brukes som en "mellommann" for å overføre filer mellom ulike protokoller, som er til stede i bokstavelig talt milliarder av applikasjonsforekomster. Forslaget om en massiv åpen kildekode-biblioteksfeil fremkalte minner fra katastrofen log4j feil fra 2021. Som Alex Ilgayev, leder for sikkerhetsforskning ved Cycode, bekymret, «kan sårbarheten i curl-biblioteket vise seg å være mer utfordrende enn Log4j-hendelsen for to år siden.»

Men følger dagens avduking av patcher og feildetaljer, ingen av sårbarhetene levde opp til hypen.

Påvirker et begrenset antall krøll-utplasseringer

Den første vulnen, en haugbasert bufferoverløpsfeil sporet under CVE-2023-38545, ble tildelt en vurdering på "høy" på grunn av potensialet for datakorrupsjon eller til og med ekstern kjøring av kode (RCE). Problemet ligger i SOCKS5 proxy-overlevering, ifølge rådgivende.

"Når curl blir bedt om å sende videre vertsnavnet til SOCKS5-proxyen for å tillate at den løser adressen i stedet for at det blir gjort av curl selv, er den maksimale lengden som vertsnavnet kan være 255 byte," heter det i meldingen. "Hvis vertsnavnet oppdages å være lengre enn 255 byte, bytter curl til lokal navneløsning og sender i stedet den løste adressen bare til proxyen."

Feilen kan tillate at feil verdi blir overlevert under SOCKS5-håndtrykket.

"På grunn av en feil kan den lokale variabelen som betyr 'la verten løse navnet' få feil verdi under et sakte SOCKS5-håndtrykk, og i motsetning til intensjonen, kopier det for lange vertsnavnet til målbufferen i stedet for å kopiere bare løst adresse der," la rådgiveren til.

Betegnelsen med høy alvorlighetsgrad gjelder imidlertid bare for en brøkdel av distribusjonene, sier nettsikkerhetsekspert Jake Williams.

"Dette er bare høy alvorlighetsgrad i svært begrensede omstendigheter," sier Williams. «Jeg tror det bare er et problem at når du har et bibliotekssårbarhet, vet du hvordan biblioteket brukes. Du må tilordne CVE forutsatt et verste tilfelle for implementering.»

Den andre krøllefeilen, sporet under CVE-2023-38546, er en lav-alvorlig informasjonskapselinjeksjonsfeil som bare påvirker libcurl-biblioteket, ikke krøllen i seg selv.

"Jeg tror dette er et større problem for sikkerhetsenheter og apparater (som henter upålitelig innhold og ofte bruker krøll under panseret)," sa Andy Hornegold i en uttalelse som reaksjon på utgivelsen av krøllfeildetaljene. "Jeg ser ikke at det er et stort problem for frittstående bruk."

Farene ved å hype opp en fiks

Utover halsbrann for cybersikkerhetsteam, kan hyping av en løsning før tekniske detaljer frigis gi en enkel seier til trusselaktører. I dette tilfellet påpeker Williams at RedHat oppdaterte endringsloggen i forkant av den offisielle curl-utgivelsen, som kunne gitt nettangripere viktig informasjon om uoppdaterte mål, hvis sårbarheten hadde vært så farlig som tidligere antatt.

Faktisk så Mike McGuire med Synopsys farene ved den økte oppmerksomheten på krølloppdateringen og skrev om det i en blogg fra 9. oktober.

"Til tross for at de ikke har ytterligere detaljer om sårbarheten, vil trusselaktører utvilsomt begynne å utnytte forsøk," skrev McGuire. "I tillegg er det ikke uhørt for angripere å legge ut falske "fiksede" versjoner av et prosjekt fulle av skadelig programvare for å dra nytte av team som prøver å lappe sårbar programvare."

Tidstempel:

Mer fra Mørk lesning