CURL repareert ernstige heap-overflowkwetsbaarheid

De ontwikkelaars van cURL hebben versie 8.4.0 van de tool uitgebracht. Daarin zit een fix voor een kwetsbaarheid die zowel betrekking had op cURL als op libcurl. Hoofdontwikkelaar Daniel Stenberg noemde de kwetsbaarheid 'het ergste beveiligingsprobleem voor de tool in tijden'.

De ontwikkelaars kondigden vorige week al aan dat de tool door twee kwetsbaarheden werd getroffen. Een daarvan had een Lage risicoklassificatie, maar de ander wordt als Zeer ernstig ingeschaald. De ontwikkelaars wilden toen nog geen details geven vanwege het risico dat de kwetsbaarheden misbruikt zouden worden. Nu schrijft Stenberg dat het in het ergste geval om een heap-overflowexploit gaat, aangeduid als CVE-2023-38545. Dit probleem had zowel betrekking op de commandlinetool als op de bijbehorende libcurl-library. CURL is een veelgebruikte tool om dataoverdracht tussen verschillende protocollen mogelijk te maken en bijvoorbeeld informatie op te halen van websites via de cli.

Om de kwetsbaarheid te misbruiken zou een aanvaller volgens Stenberg een te lange hostnaam moeten invoeren. Een reguliere hostnaam in het dns kan volgens hem 253 bytes zijn terwijl de url-parser van libcurl tot 65.535 bytes accepteert. Daarom zou het in de praktijk eigenlijk niet voor kunnen komen dat er een dusdanig lange hostnaam ingevoerd zou worden, dat er een heap-overflow getriggerd wordt.

De bug zit in libcurl tussen versies 7.69.0 en 8.3.0. Oudere versies en versies vanaf het nu uitgebrachte 8.4.0 zijn niet kwetsbaar. De bug zit al jaren in de tool, maar het is niet bekend of die daar ooit actief is misbruikt.

Reacties (49)

[Kees]

Let er wel op dat dit een sneer is naar 'critical cve's' uit het verleden. Curl heeft niet vaak last van kwetsbaarheden, en deze is niet 'kritiek' alleen maar 'high'. En is ook lastig te misbruiken omdat het alleen maar mis gaat als curl een socks proxy gebruikt en daar kennis van heeft. Die setup ben ik nog niet heel vaak tegengekomen.

De sneer is naar "kritieke" cve's uit het verleden, waar bijvoorbeeld een overflow op een 'wait timer' als zeer kritiek werd gemarkeerd; als je op de cli aan curl meegaf dat hij maximaal xx seconden mocht wachten, en je wilde dat curl tot ver na de hittedood van het universum ging wachten, dan kon het voorkomen dat er een 'overflow' optrad en curl minder lang ging wachten dan dat je dacht. Die bug werd toen neergezet als een 'zeer ernstige kwetsbaarheid' wat natuurlijk flauwekul is.

Door deze relatief milde kwetsbaarheid te markeren als 'de ernstigste kwetsbaarheid in curl in tijden' wil hij benadrukken dat curl al heel lang geen grote beveiligingsproblemen heeft gehad en dat de bugs die door andere mensen als 'kritiek' zijn gemarkeerd helemaal niet zo'n hoge score horen te hebben.

Het is dus eigenlijk gewoon Daniel die roept dat ze eindelijk een keer een echte kwetsbaarheid hebben gevonden, na al die bogus reports. De kwetsbaarheid an sich is niet alarmerend.

[Reactie gewijzigd door Kees op 22 juli 2024 13:20]

[Bor]

Aanvullend is er een standaard manier om tot CVE inschaling te komen die voor alle CVE's wordt gebruikt. Misschien wel mede om te voorkomen dat ontwikkelaars kwetsbaarheden op basis van onderbuikgevoel of met een bepaald doel inschalen. Kwetsbaarheden met hoge impact doen bijvoorbeeld ook iets met het imago van software en het bedrijf hierachter.

Een voorbeeld inclusief handige calculator vind je hier: https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator

[Reactie gewijzigd door Bor op 22 juli 2024 13:20]

[Tubby]

Ja, dat ik snap hoe dat tot stand komt, maar er zit een perverse prikkel voor security bedrijven om dat hoog in te schalen zodat ze veel paniek kunnen zaaien en daarmee producten kunnen verkopen.

Nou ben ik de laatste die zal zeggen dat het onzin is en CVE classificatie hoog verdienen het om op impact geschat te worden. Maar daarmee is de kous ook af, curl icm met deze config gebruiken wij intern niet. Klaar; kastje dicht poppetje gezien

[Bor]

Wat voor producten denk je door een hoge CVE te kunnen verkopen? Het zijn doorgaans ook geen security bedrijven die producten aanbieden in relatie tot de CVE die het inschalen.

[Tubby]

weet niet of je ooit de pricing van Snyk hebt bekeken?

of de hogere tiers van gitlab bevatten ook security informatie dashboards, management gaat goed op dat soort overzichten hoor

[RiDo78]

Ach, bij het bedrijf waar ik werknis het internationale management helemaal wild van Tenable. Een fantastisch product wat in alle landen en in alle dochterbedrijven verplicht moet worden uitgerold.

Welnu, Red Hat Satelite heeft die kwetsbaarheden ongeveer even snel gevonden als Tenable. Maar in tegenstelling tot Tenable snapt Satellite wel wat backporting is. Zo gaat Tenable over de zeik als het op RHEL 7 systemen openssl 1.0.2 aantreft ipv 1.1.x. Dat de 1.0.2 versie van RedHat gewoon gepatched is, ziet hij niet.

Maakt dat voor het management uit? Nee, want Satellite kan out-of-the-box geen exporting doen naar PowerBI en Tenable wel. Daarnaast is Satellite beperkt tot RHEL en is Tenable platform onafhankelijk.

Dus om terug te komen op je vraag, producten waarbij het management zich kan vergapen op mooie rapportjes en grafiekjes die tonen dat zij ‘in control’ zijn. En hoe meer kritieke CVE’s er zijn hoe meer het management een warm gevoel krijgt als die kwetsbarheden binnen de gestelde tijd worden opgelost.

(Dat wij als ICT’ers die tools vaak niet nodig hebben omdat we ofwel alles patchen ofwel geavanceerde patchmanagement systemen gebruiken is dan een nietszeggend derail)

[MrMonkE]

"(Dat wij als ICT’ers die tools vaak niet nodig hebben omdat we ofwel alles patchen ofwel geavanceerde patchmanagement systemen gebruiken is dan een nietszeggend derail) "

Aah maar soms krijg je geen response. En dan zeg je 10x "insecure.. productie password sa/leeg.. niet goed.. ga laten aanpassen!" maar dat gebeurde niet dus paar weken later landelijke media aandacht. Top job, manager! 300 euro manuur bespaard ten koste van pagina 3 van de telegraaf.

[Bor]

De producten van Tenable leveren doorgaans prima resultaten. Ze zijn niet voor niets een marktleider op dit vlak. Hun producten worden o.a. binnen fortune 500 bedrijven en door vele pentesters gebruikt. Elke vulnerability scanner / mangement oplossing zal false positives kennen. Dat is niet erg wanneer je dat kan verklaren zoals je in bovenstaande reactie doet. Het product hierom semi afschrijven zoals je lijkt te doen is schromelijk overdreven. Zoals je zelf al aangeeft heeft Red Hat Sattelite ook zijn nadelen nog los van het feit dat het geen brede vulnerability scanner / management oplossing is.

[Tubby]

onze pentester heb ik ook wel eens Tenable zien gebruiken, maar die werkt het wel even uit tot een rapport met oplossingsrichtingen voor ons als developer

[laurxp]

Het hele probleem is nou juist dat de NVD regelmatig een compléét verkeerde inschatting maakt.

Die eerder genoemde "wait timer" bug kreeg van hen bijvoorbeeld een 9.8 / 10. Mind you, dat gaat om een bug die al vier jaar geleden gepatcht is, en die er slechts voor zorgde dat een retry timer van 25 dagen(!) werd gezien als 5 minuten. Je zal serieus moeite moeten doen om een bug te vinden met een kleinere impact, en dat noemen ze een 9.8. De score van de NVD heeft nul basis in realiteit en is daardoor compleet betekenisloos.

[Jerie]

CVSSv3 is nou exact waar de curl auteur afgelopen maanden kritiek op heeft geleverd afgelopen maanden.

Het is dan ook natte vingerwerk.

[SpankmasterC]

Dit had ik helemaal niet door toen ik vanochtend naar de CVE keek, blijkt maar weer dat sarcasme/cynisme moeilijk te lezen is in geschreven berichten.

[Kees]

Het is wel degelijk een kwetsbaarheid die mogelijk uitgebuit kan worden, dus het hoort zeker wel een cve te krijgen, en in die cve moet je netjes zijn.

Maar door alle aankodigingen en hype vooraf had ik zelf iets ernstigers verwacht; maar daarbij moet ik wel meteen opmerken dat ze heel eerlijk de hele tijd hebben gesproken over een 'high' met de nadruk dat het niet 'kritiek' was.

Zie ook: https://daniel.haxx.se/bl...-that-is-wrong-with-cves/
en: https://daniel.haxx.se/blog/2023/09/05/bogus-cve-follow-ups/

[Bor]

Dit had ik helemaal niet door toen ik vanochtend naar de CVE keek, blijkt maar weer dat sarcasme/cynisme moeilijk te lezen is in geschreven berichten.

Dat is dan ook direct (mede) het punt. Het probleem waar de ontwikkelaar tegen ageert houd hij zo zelf in stand.

[latka]

Als het probleem het systeem is, is de spot ermee drijven en de irrelevantie ervan aantonen een goede wijze om tot veranderingen te dwingen. Zolang er gestuurd wordt op de score van een cve en een foute score niet tot represailles leid gebeut er niet zoveel. Dus maak iedere poep een 10 en de hoeveelheid werk loopt binnen de kortste keren op en de mensen die over budgetten gaan hebben ineens een mening.

[Bor]

Het probleem is niet het systeem; dat werkt op zich prima. Het issue wat de ontwikkelaar omschrijft is de inschaling door een enkele partij. Daar zou je iets aan willen doen. Let wel dat dit de mening van de ontwikkelaar in kwestie is; geen breed geaccepteerd iets. Het systeem, waarbij er eigenlijk geen goed geaccepteerd alternatief is, frustreren werkt averechts. Het brengt het systeem in diskrediet, overbelast mensen die kwetsbaarheden moet wegnemen en legt de focus op het oplossen van kwetsbaarheden die lagere prioriteit kunnen hebben.

[latka]

Het lijken er meer te zijn.

[Bor]

Het probleem wat hierbij meespeelt is dat een enkele score natuurlijk nooit het hele plaatje kan weergeven; het geeft namelijk geen context. Je behoort nooit blind van de CVSS score uit te gaan maar altijd te kijken wat de kwetsbaarheid voor jou in jouw specifieke context betekent. Daarbij speelt ook nog eens dat "getroffen bedrijven en ontwikkelaars" (die verantwoordelijk voor de kwetsbare software) snel geneigd zijn de CVSS score zo laag mogelijk te proberen te houden; grote lekken zijn doorgaans niet best voor het imago.

[Tubby]

An sich fijn dat ze wat minder meegaan in het 'kritieke' feestje.

Imho wordt er veel paniek gezaaid met CVE's en mogelijke exploits, maar als puntje bij paaltje komt zijn ze moeilijk te misbruiken. Vaak moeten ze echt "gestapeld" worden met andere CVE's om tot een resultaat te komen.

[Bor]

Je stelt dit nu wel heel algemeen wat in mijn ogen niet klopt; het is een behoorlijke generalisering. CVE's met een verkeerde CVSS score (waar het hier over gaat) zijn uitzonderingen en geen regel. "Als puntje bij paaltje komt zijn ze moeilijk te misbruiken" is ook lang niet altijd waar. Zo komen er met enige regelmaat unauthenticated RCE zaken voorbij (als voorbeeld) waar gewoon kant en klare exploits voor beschikbaar zijn die je zonder al te veel kennis kan gebruiken.

[Reactie gewijzigd door Bor op 22 juli 2024 13:20]

[Tubby]

Met de Struts2 CVE ook wel een nachtje moeten doortrekken dus ik weet wel wat er kan/mogelijk is en ik vind het gezond dat er structureel aandacht is.

Anders gesteld; in de score bepaling / inschatting wordt vaak onvoldoende meegewogen welke configuratie toegepast moet zijn om het te kunnen misbruiken. (vind ik). bij de log4shell thingies was (te?) veel ruis over welke specifieke jars nu wel of niet kwetsbaar waren.

In de eerste uren van een CVE heb je dan toch het meeste aan de reproductie-scripts om te testen of het jouw applicatie behelst en ik drijf dus meer op het concept of het voorpagina-nieuws (hier of op twitter) is dan de daadwerkelijke score (want dat ijlt ook na).

[delphium]

Dankjewel voor de duiding. Ik had tot nu toe echt niet door dat dit sarcastisch was.
Ik vond het eigenlijk vrij irritant, omdat ik na de aankondiging al helemaal op scherp stond, om vijf servers direct te patchen.

[Mellow Jack]

Dan ben je geen echte "diehard". Onze Linux dudes hebben het er al eventjes over zonder alteveel haast om onze 600+ servers te patchen

Bij een echte critical had ik dit bericht veel eerder verwacht

[delphium]

Ik ben autodidact en heb geen collega's die bekend zijn met Linux. Ben ik dan geen echte "die hard"? Ik zou het niet weten. Ik gebruik al twintig jaar Linux als daily driver.
Ik ben ook autist. Daardoor neem ik vaak dingen letterlijk. Misschien heeft het daar iets mee te maken?

[GeroldM]

Probleem is dus dat Microsoft sinds het uitbrengen van Windows 10 standaard curl meelevert.

Dus je kan je Linux dozen patchen, maar als je je WIndows dozen vergeet, dan heb je nog altijd niet dit CVE beveiligingsprobleem opgelost. Microsoft levert namelijk een curl met Windows mee die geen SFTP onderdteunt (dus een speciale build). En het is een versie die in de getroffen reeks valt.

Open een command-prompt of Powershell sessie in Windows 10, Windows 11, Server 2016, Server 2019 of Server 2022. Tiep dan: curl -V

En je krijgt het versie nummer van curl terug. Is misschien een verassing als je denkt dat je Windows doos buiten schot blijft omdat curl niet is geinstalleerd. Maar helaas, Microsoft heeft dat al voor jou gedaan.

[Jerie]

Tor gebruikt het, o.a. Shadowsocks ook. Dus wat dat betreft zorgelijk.

Je kunt ook een VPN opzetten dan dan ipv middels routing het via een proxy exporteren.

[DDX]

Maar wat is nu precies het risico, het is niet alsof curl een server is die toegang geeft tot data ?

[sir_huxley]

In het ergste geval betekend dat dat je externe code kan uitvoeren. Dus onbetrouwbare code die op zijn beurt weer probeert een andere kwetsbaarheid uit te buiten tot dat genoeg toegang hebt tot een systeem

[Reactie gewijzigd door sir_huxley op 22 juli 2024 13:20]

[bwerg]

Ik vraag me af wie dit een -1 geeft want dit is precies de reden dat overflows eng zijn, en d'r zijn tal van technieken om daar misbruik van te maken (en ook weer tal van technieken om dat misbruik tegen te gaan).

Ja, je kan ook gewoon een overflow doen met random bitjes en dan crasht de boel gewoon. Daar ligt niemand wakker van, een crash bij foute data heeft weinig impact en van dat soort bugs zijn er wel meer.

[Patriot]

EDIT: Ik ben dom Ik zat in mijn hoofd met de oude CVE, die dus onterecht was.

EDIT2:
Nog even voor de goede orde, dit heb ik gezegd:

Dat kan hier niet. Dat kan alleen bij een buffer overflow, een specifiek soort overflow waar hier geen sprake van is. De bug in kwestie kan alleen maar zorgen voor een onverwachte waarde van de vertraging waarmee curl mislukte requests opnieuw probeert uit te voeren.

Dat klopt niet, dat ging dus over de 'vorige' CVE die eigenlijk geen CVE had moeten zijn.

[Reactie gewijzigd door Patriot op 22 juli 2024 13:20]

[YopY]

curl is ook een library die door miljarden installaties van software gebruikt wordt; zie https://everything.curl.dev/project/users voor een kleine indicatie. Dwz, als er een zwakte in zit, zal er wel een combinatie van factoren bij een gebruiker zijn waarbij het misbruikt kan worden.

[Reactie gewijzigd door YopY op 22 juli 2024 13:20]

[DDX]

Ah ja op die fiets.
Ik zat alleen te denken aan curl zoals ik het wel eens op de commandline gebruik.

[Mellow Jack]

Is ook precies hetzelfde

[latka]

Ach, de installatie instructie van een groot aantal tools was een paar jaar terug "curl http://... - | sudo sh". Het lijkt er gelukkig op dat dit patroon een snelle dood gestorven is, maar er zijn er vast nog wel een paar over. Als je al root bent dan drop je de sudo et voila: remote root in a box.

[DDX]

Zoiets bedoel je ? :

https://www.cyberciti.biz...epel-repo-on-an-rhel-8-x/

'sudo yum -y install https://dl.fedoraproject....ease-latest-8.noarch.rpm'

[latka]

Nee, letterlijk: curl https://blabla.com/download/nodejs.sh | sudo sh - op de voorpagina bij node. Alles wat je niet moet doen als werk instructie voor mensen die niet beter weten en dan roepen dat het veilig is want https...

[xzaz]

Sure, there is a minuscule risk that someone can find this (again) before we ship the patch, but this issue has stayed undetected for years for a reason

Dit is altijd wel een enorme grote aanname met dit soort zaken.

Het kan al lang bekend zijn maar gewoon niet niet gemeld en er kan al jaren gebruik van zijn gemaakt. Ook dit is een aanname, maar simpel 'wij wisten het niet dus niemand wist het' is geen goed argument.

[ACM]

In dit geval is de aanname aardig valide; er zijn domweg niet zoveel gebruikers die SOCKS5-proxies gebruiken... en dan moet je bovendien dus het voor elkaar gebruiken dat iemand anders zo'n ongebruikelijk lange hostname krijgt en doorgeeft aan z'n lekke curl.

[BernardV]

Er zullen zeker niet veel gebruikers zijn die SOCKS proxies gebruiken, maar laat het naast normaal TOR gebruik ook een optie zijn om een TOR proxy op te zetten welke SOCKS gebruikt.
Deze zijn zeker in gebruik en ook vrij toegankelijk in sommige gevallen.
Dan heb je waarschijnlijk ook gelijk een doelgroep waarbij mogelijke code execution relevant kan zijn voor partijen.

//EDIT: Zo heb ik er een thuis draaien met een exit node in BE voor grandprix radio.

[Reactie gewijzigd door BernardV op 22 juli 2024 13:20]

[gimbal]

Dat staat er niet. Er staat dat het jarenlang niet gedecteerd was.

... door de onderhouders. Het is simpelweg een indicatie van hoe verstopt het probleem zat. Je hebt toch echt het verkeerde stuk gequote als het je missie is om met de vinger te zwaaien.

[Anonymoussaurus]

De changelog die in dit artikel (vreemd genoeg) mist inclusief wat bronnen en andere informatie:

• https://curl.se/changes.html#8_4_0
• https://curl.se/docs/security-h.html
• https://hackerone.com/reports/2187833

[MrKite]

En dan ook nog maar eens alleen wanneer het in combinatie met een SOCKS5 proxy gebruikt wordt. Dat zal tegenwoordig niet meer zo vaak voorkomen. Dit staat uitgelegd in de CVE die in het artikel gelinkt wordt.

[Reactie gewijzigd door MrKite op 22 juli 2024 13:20]

[stefklep]

Missen we niet in dit artikel een stukje over de "This flaw makes curl overflow a heap based buffer in the SOCKS5 proxy handshake." Vooral het gedeelten SOCKS5 is denk wel essentieel om te vermelden.

[riotrick]

Ja dat maakt nogal een verschil

[rusman]

Voor wie het interessant vind, hier is de volledige timeline en communicatie van de vulnerability te zien: https://hackerone.com/reports/2187833

[Anonymoussaurus]

Klopt, staat ook hier: Anonymoussaurus in 'CURL repareert ernstige heap-overflowkwetsbaarheid'

[rusman]

Thanks!

[Big Mama]

Om de kwetsbaarheid te misbruiken zou een aanvaller volgens Stenberg een te lange hostnaam moeten invoeren. Een reguliere hostnaam in het dns kan volgens hem 253 bytes zijn terwijl de url-parser van libcurl tot 65.535 bytes accepteert. Daarom zou het in de praktijk eigenlijk niet voor kunnen komen dat er een dusdanig lange hostnaam ingevoerd zou worden, dat er een heap-overflow getriggerd wordt.

En als je nou eens geen DNS gebruikt?
Als je in je hosts-file een naam van >255 karakters toevoegt, dan wordt die meegestuurd in de URI.
Net getest op Linux: een hostname van 500 tekens werkt prima en wordt niet afgekapt.

[laurxp]

Tweakers vertaalt het een beetje ongelukkig, maar wat de originele blogpost probeert te zeggen is dat het heel lastig is om deze bug per ongeluk te triggeren. Je moet dan namelijk iets obscuurs doen dat nooit zal werken door de protocol-beperkingen van SOCKS5 - ongeacht de implementatie. Je kan daardoor met vrij grote zekerheid zeggen dat nul mensen bewust hun SOCKS5-proxy een hostname van meer dan 255 bytes laten resolven met bijv. een hosts-file.

CURL hoeft daarom bij het fixen van de bug geen rekening te houden met eventuele workarounds - ze kunnen gewoon een error geven als je een hostname van >255 bytes probeert te gebruiken in combinatie met een SOCKS5-proxy.