Mozilla repareert twee use-after-free-zerodays in Firefox

Mozilla heeft twee kwetsbaarheden gerepareerd in Firefox waarmee een aanvaller op afstand een compleet systeem kon overnemen. Veel details over de bugs zijn niet bekend, maar de browsermaker zegt dat de kwetsbaarheden actief in het wild werden misbruikt.

Mozilla heeft twee afzonderlijke bugtrackers geopend voor de kwetsbaarheden. Van beide is nog geen gedetailleerde informatie beschikbaar. Het gaat om CVE-2020-6819 en CVE-2020-6820. Beide bugs zijn use-after-free en richten zich op memory corruption. De eerste kwetsbaarheid maakt gebruik van de nsDocShell-destructor, de andere van ReadableStream. Beide functies kunnen een use-after-free veroorzaken. Daarmee zou het mogelijk zijn het systeem van een gebruiker over te nemen door alleen een bepaalde website te bezoeken. Twee beveiligingsonderzoekers ontdekten de kwetsbaarheden, maar hebben er nog geen details over bekendgemaakt. Die volgen later. De onderzoekers zeggen daarbij ook informatie te hebben over eenzelfde soort lek in andere browsers.

Mozilla zegt dat het aanwijzingen heeft dat de zerodays actief in het wild werden misbruikt, maar ook daarover zijn geen details bekend. Het bedrijf raadt alle gebruikers aan Firefox te updaten naar versie 74.0.1 of Firefox ESR 68.6.1.

Reacties (24)

[BikkelZ]

Beide bugs komen uit oudere delen die nog in C++ geschreven zijn. nsDocShell is volgens mij de wrapper rondom het document, dus alle buttons van de interface.

[Belgar]

RUST had hier alleen niet de "root cause" verholpen. Beide bugs ontstaan eigenlijk na een "race-condition". Die kan in principe nog steeds optreden met RUST, alleen was de ontstane situatie waarschijnlijk wel een stuk moeilijker uit te buiten. Met RUST hadden de fouten waarschijnlijk geleid tot crashes of denial-of-service-achtige problemen, niet tot directe code execution.

[DCK]

Nee dat begrijp je verkeerd. In dit geval had Rust de "data race" compile-time voorkomen. Het ownershipmodel van Rust voorkomt dit soort data races compile time, en dit had ook niet runtime tot een denial of service geleid. De code had gewoon niet gecompileerd. Een use-after-free is niet mogelijk in Rust dat geen "unsafe" keyword gebruikt.

Nitpick: waarom schrijf je Rust in allemaal hoofdletters? Het is nergens een afkorting voor, het is gewoon "Roest". Zelfs FORTRAN schrijf je vandaag de dag als "gewoon" Fortran

[BikkelZ]

In ieder geval geen code execution inderdaad. Rust is compile time secure en met een race condition zou het eventueel wel kunnen, al zou ik geen voorbeeld kunnen geven hoe uit mijn hoofd.

[Niosus]

Het is al een hele tijd geleden dat ik Rust gebruikt heb, maar van wat ik mij herinner zou zelfs een race condition geen use-after-free mogen toelaten. Elk object heeft een "owner", en om een object door te geven moet je ofwel de ownership mee doorgeven, of een referentie geven. Aangezien dat die ownership altijd getraceerd kan worden, kunnen ze at compile time controleren en garanderen dat je nooit een referentie krijgt naar een object dat niet meer bestaat. Ze laten je letterlijk niet toe om een object te verwijderen als het nog mogelijk is dat er nog referenties naar bestaan.

Nu mijn ervaring is puur in een single-threaded omgeving. Ik weet niet hoe ze dit multithreaded aanpakken. Maar in principe zijn al die (of toch de meeste) memory fouten volledig onmogelijk in Rust (zonder unsafe block te gebruiken). De code compileert letterlijk niet als je het mis doet.

[BikkelZ]

Dat is ook mijn twijfel; single-threaded kan het sowieso niet gebeuren dankzij de compiler, maar met meerdere threads tegelijkertijd zou het misschien kunnen om bijvoorbeeld te crashen.

[84hannes]

Communicatie tussen threads gebeurt naar mijn weten met abstracties als pipes. Natuurlijk kan er een bug in zo’n abstractie zitten en misschien kun je met unsafe-Rust toch gedeeld geheugen opzetten, maar in principe hoeft de programmeur zich er ook bij multi-threaded applicaties niet druk te maken om het geheugenbeheer.

[84hannes]

Fijn dat je mijn vraag beantwoord voordat ik hem gesteld had

Mijn vraag was: ‘Steeds meer onderdelen van Firefox zijn in Rust geschreven, juist om geheugenbeheer foutloos te maken. Is dit een groot gebrek in Rust of is het oude C/C++ code?’

[psychicist]

Bovendien vraag ik me af in hoeverre een systeem daadwerkelijk overgenomen kan worden en specifiek welke besturingssystemen hiervoor vatbaar zijn. Als het hiet gaat om Windows, Linux, macOS of iets anders, moet dat ook gewoon expliciet benoemd worden en uitgelegd worden, waarom het hele systeem overgenomen kan worden.

Als er in een besturingssysteem een adequate mate van isolatie zit tussen applicaties en het besturingssysteem zelf, zou dat namelijk nooit moeten kunnen.

Ik dacht dat technologieën zoals SELinux en Apparmor hier specifiek voor bedoeld waren en anders zijn er ook containers om onveilige applicaties zoveel mogelijk te isoleren.

[GertMenkel]

Als er in een besturingssysteem een adequate mate van isolatie zit tussen applicaties en het besturingssysteem zelf, zou dat namelijk nooit moeten kunnen.

Dit klinkt een beetje zoals de sandbox die Android en iOS hebben. Op Linux wordt dit geprobeerd met dingen als Flatpak en Snap. Windows heeft dit met zijn Store-applicaties maar ik zie maar weinig mensen interesse tonen in UWP-apps.

Extra security wordt op zekere mate ook gedaan, alhoewel SELinux/Apparmor volgens mij niet geweldig werken (omdat Firefox een bestand naar een willekeurige locatie moet downloaden wil het niet een hoop irritatie veroorzaken).

Firefox gebruikt op Linux o.a. seccomp om syscalls te beperken. Op Windows hebben low integrity levels geholpen, maar dat is volgens mij niet meer mogelijk als ik het zo lees. Daar zou je wel Firefox kunnen draaien met Application Guard Extensions om de sandbox nog vollediger te maken (dat draait een proces in een VM voor security-redenen, maar geeft beperkingen met dingen als hardware-acceleratie).

Als je bent ingelogd als normale gebruiker (geen admin), je zaken updatet en op Windows de UAC slider helemaal naar boven zet (Windows Vista-niveau van UAC popups) dan zal een gehackte browser weinig kunnen doen behalve je bestanden versleutelen. Systeemrechten krijgen is dan erg moeilijk. Door de geavanceerde beveiligingen die Microsoft in Windows Defender heeft ingebouwd aan te zetten, zoals geforceerde ASLR, ACG, SEHOP, code integrity guard, enzovoorts, ben je nog veel veiliger (veel staat default uit omdat oude, slechtgeschreven applicaties zoals de Flash installer er niet mee overweg kunnen).

Kortom: gebruik UWP-applicaties/Flatpaks/Snaps, de sandboxing features van Windows, log nooit in als administrator en je hebt een extra laag beveiliging. Dat betekent niet dat je veilig bent aangezien ieder OS lekken heeft, maar het voegt wel wat defence in depth toe.

[Eonfge]

Even inhaken op Firefox en Flatpak, deze is in ontwikkeling en is nu op het beta kanaal beschikbaar:
https://www.omgubuntu.co....icial-firefox-flatpak-app

De verwachting is dat Firefox 75 (Dus over 3 weken) officieel beschikbaar komt op Flathub. Daarmee is een van de grootste aanvalsvectoren op een modern systeem veilig ingepakt.

Wat betreft andere risico groepen: PDF readers staan al op Flathub, net zoals Steam en de meeste mediaspelers, dus hiermee maak je jouw systeem een stuk veiliger. Zie hier voor de complete collectie:
https://www.flathub.org/home

Edit
Firefox op Flathub is nu uit:
https://www.flathub.org/apps/details/org.mozilla.firefox

[Reactie gewijzigd door Eonfge op 24 juli 2024 14:58]

[F_J_K]

Een use-after-free is (afaik, ianad...) overigens dat, zoals de naam al suggereert, het geheugen alsnog (hier door Firefox) wordt gebruikt na vrijgave. Dan kan dat geheugen dus ook worden gebruikt door andere processen, zoals dat van de aanvaller.

[R4gnax]

Een use-after-free is (afaik, ianad...) overigens dat, zoals de naam al suggereert, het geheugen alsnog (hier door Firefox) wordt gebruikt na vrijgave. Dan kan dat geheugen dus ook worden gebruikt door andere processen, zoals dat van de aanvaller.

Nee. Een use-after-free betekent hier concreet dat geheugen voor een bepaald doeleinde binnen een proces doorgebruikt wordt, terwijl het binnen dat proces vrijgegeven is voor ander gebruik binnen datzelfde proces.

Wanneer een proces geheugen probeert te accessen wat buiten de geheugenruimte van het proces valt, dan krijg je een segmentation fault.

[Reactie gewijzigd door R4gnax op 24 juli 2024 14:58]

[mailis]

Thanks voor de uitleg!

Omdat in de titel "use-after-free-zerodays" stond, dacht ik dat dit al bekende zerodays waren die nu door de hackers gratis worden aangeboden. In het artikel stond geen specifieke uitleg of definitie, dus goed dat je dit nog even toelicht (voor mij in ieder geval )

[R4gnax]

Even nog ter aanvulling dan;

Een user-after-free als deze komt er op neer dat één deel van de applicatie gebruikt kan worden om de data die in het geheugen zit zo te manipuleren (bijv in Firefox' geval via speciaal geprepareerde JavaScript), dat een ander deel wat ondertussen eigendom over dat geheugen heeft gekregen misbruikt kan worden om bijv. een klein stukje code uit te voeren met de normale rechten van de gebruiker.

Remote code execution, dus.

Andere vormen er van kunnen neerkomen op het aaneenschakelen van voldoende van deze geheugen-corrupties in een domino-effect om alsnog remote code execution to krijgen, maar ook om simpelweg bij gevoelige settings te komen. Session-cookies jatten, bijv. Of in-memory een paar bytes flippen zodat een instelling om ouderwetse (totaal gebroken) encryptie-standaarden weer terug aan te zetten, zodat daarna een version downgrade attack uitgevoerd kan worden.

Maar alsnog; allemaal binnen hetzelfde proces of dezelfde process-space.

[Reactie gewijzigd door R4gnax op 24 juli 2024 14:58]

[michielRB]

In Fedora is deze gister ochtend gepatched:

rpm -q firefox --last
firefox-74.0.1-1.fc31.x86_64 zo 05 apr 2020 11:46:43 CEST

[sfranken]

In Gentoo ook:

emerge --search firefox
www-client/firefox
Latest version available: 68.6.1

www-client/firefox-bin
Latest version available: 74.0.1

[Reactie gewijzigd door sfranken op 24 juli 2024 14:58]

[The Zep Man]

In Fedora is deze gister ochtend gepatched:

Je bedoelt dat een nieuwe versie is uitgekomen in de repositories, die de huidige versie vervangt.

In Arch Linux is de nieuwe versie al drie dagen beschikbaar.

[obimk1]

En FF op mijn Mac is nu al geüpdatet naar 74.0.1. (automatisch)

Kudos!

[CH4OS]

Het staat je vrij nieuws en downloads te tippen via https://tweakers.net/submit/

[Lizard]

Bovendien als je bij de downloads kijkt, is die daar wel al op 3 april genoemd. Alleen was er nog geen fp artikel van: downloads: Mozilla Firefox 74.0.1

[Beta]

Iemand moet Tweakers wel tippen over dit nieuws. Als dat pas gisteren (op een zondag) binnenkwam dan is het niet vreemd dat het vandaag wordt gepubliceerd.

[vosManz]

En op diezelfde dag, razendsnel dus, heeft Tweakers er al over bericht via de Downloads van Firefox. Dit artikel kun je dus beter zien als een aanvulling daarop met wat uitgebreidere informatie.

downloads: Mozilla Firefox 74.0.1