Mozilla fixt twee actief misbruikte kwetsbaarheden in Firefox met patch

Mozilla fixt twee kwetsbaarheden in Firefox 97.0.2, Firefox ESR 91.6.1, Firefox for Android 97.3, Focus 97.3 en Thunderbird 91.6.2. Mozilla weet dat die kwetsbaarheden actief misbruikt zijn en noemt ze 'kritiek'.

De patch voor de verschillende Firefox-browsers werd zaterdag door Mozilla uitgebracht en is sindsdien te downloaden. De zerodays zijn beide use-after-free-kwetsbaarheden, de een in XSLT-parameterprocessing, de ander in het WebGPU IPC-framework. Een dergelijke kwetsbaarheid zorgt ervoor dat een programma geheugen probeert te gebruiken dat vrijgemaakt is. Als een kwaadwillende die kwetsbaarheid misbruikt, crasht het programma en kan op een apparaat code uitgevoerd worden zonder toestemming, legt Bleeping Computer uit.

De twee kwetsbaarheden zijn ernstig, schrijft Mozilla. Volgens het bedrijf zijn beide kwetsbaarheden 'in het wild' misbruikt. De kwetsbaarheden hebben de CVE-codes CVE-2022-26485 en CVE-2022-26486 gekregen. Het ontdekken van de kwetsbaarheden is door Mozilla toegeschreven aan onderzoekers van het Chinese securitybedrijf Qihoo 360 ATA. Mozilla en Qihoo 360 ATA hebben niet meer details gegeven over hoe de kwetsbaarheden misbruikt zijn. Het komt niet vaak voor dat in Mozilla-code een zeroday gevonden wordt.

Reacties (18)

[GoBieN-Be]

Even verduidelijken dat in onderstaande versie nummers de kwetsbaarheid verholpen is.
De Nederlandse tekst in het artikel is verwarrend vind ik.

Firefox 97.0.2
Firefox ESR 91.6.1
Firefox for Android 97.3
Focus 97.3
Thunderbird 91.6.2

De kwetsbaarheden zaten dus in de oudere/lagere versies.

[Qalo]

Ja, daar wilde ik ook op reageren. Er kan beter staan: "Mozilla heeft twee kwetsbaarheden gefixt". Nu lijkt het erop dat de fix met een volgende versie dan de genoemde software nog moet komen.

Maar inderdaad: de kwetsbaarheden zijn met deze versies juist verholpen. Dus voor diegenen die net de update hebben doorgevoerd: je bent hiermee (weer) veilig(er).

[Hackus]

Even verduidelijken dat in onderstaande versie nummers de kwetsbaarheid verholpen is.
De Nederlandse tekst in het artikel is verwarrend vind ik.

Firefox 97.0.2
Firefox ESR 91.6.1
Firefox for Android 97.3
Focus 97.3
Thunderbird 91.6.2

De kwetsbaarheden zaten dus in de oudere/lagere versies.

Focus for iOS is versie 97.0 en in Linux is er nog geen update van Thunderbird.

[Tweak3D]

Dank je .. daar was ik naar op zoek.. was even bang dat mn huidige versie 97.0.2 nog op een update wachtte

[Urk]

Dus bijv Firefox v94 is ook kwetsbaar? Of alleen v97.0 en v97.0.1?

[ToolBee]

En niemand die het over de backdoors en andere grollen die ze bij Qihoo uithalen?

[Cristan]

Firefox is een grote driver achter de rust programmeertaal en 1 van de grote voordelen hiervan is dat hier use after free aanvallen niet meer werken. Maar als je de statistieken erbij pakt, dan zie je dat maar zo'n 10% van de code van Firefox rust is en C en C++ samen 42% zijn, dus vandaar dat zulk soort vulnerabilities nog mogelijk zijn.

[mrmrmr]

Zo te lezen gaat het om "use after free", het gebruiken van geheugen dat al is vrijgemaakt. Dat soort kwetsbaarheden in C is makkelijk te voorkomen door pointers te controleren voor elk gebruik: if (Var != NULL) en bij free moet de pointer op NULL zijn gesteld.

CERT: MEM00-C, MEM01-C, MEM30-C.

[Monochrome]

Eeh, nee, zo simpel is het helaas niet.

void *ptr = malloc(10);
some_function_or_method(ptr);
free(ptr);
ptr = 0;

Nu kan some_function_or_method() nog steeds ergens een kopie van ptr hebben opgeslagen en op een later moment per abuis gebruiken (use-after-free). Een stuk ingewikkelder probleem (en oplossingen, pointer references bijhouden enzo) dan jij schetst.

[Reactie gewijzigd door Monochrome op 25 juli 2024 19:09]

[mrmrmr]

Dit is ernstig foute code, @Monochrome.

Je bezwaar is ook niet correct. Stel dat de functie een global pointer legt naar ptr dan is dat fout. Doe dat niet.

[Monochrome]

Nou, excuus dat m'n code niet gaat compilen, dat was niet m'n punt. Mijn punt is dat veel use-after-free vulns voortkomen uit het feit dat er wel degelijk meerdere kopieen van een pointer gemaakt worden voordat free() gecalled wordt. Dat hoeven niet per se globals te zijn, het kan ook een lokale context zijn ergens. Nevertheless, ik vind je eerdere stelling te kort door de bocht. Als jij bovenstaande 'niet correct' vindt, fine.

[mrmrmr]

Of iets wel of niet compileert is geen maatstaf in deze discussie.

Ik had al voor jouw bericht in een ander bericht aangegeven dat complexiteit een reden is voor dit soort fouten, daar zijn we het over eens. Ik schreef ook dat complexiteit vermeden moet worden.

Waar ik bezwaar tegen maakte is dat de code die je geeft een aantal basisfouten met geheugenallocatie bevat. Je declareert een void pointer en voert meteen een allocatie uit. Je controleert niet of de allocatie is gelukt, je gebruikt een ongedeclareerde functie, je doet iets wat je niet moet doen in een functie, de return van de functie wordt niet gecontroleerd en je gebruikt niet de voorgeschreven p=NULL stijl. Dat heeft niets met complexiteit te maken maar met veilig en netjes programmeren.

Stel dat het wel correcte code was. Als je automatische lokale variabelen gebruikt in de functie is er niets aan de hand, want dat wordt ook automatisch bevrijd na het sluiten van de functie. Alloceer je iets in een functie zonder vrijgave dan is er geheugen dat niet meer freed kan worden. Dat is een geheugenlek en een programmeerfout. Als je buiten de context van de functie in de functie aangemaakt geheugen aanspreekt kun je het waarschijnlijk niet compileren.
Jouw code is lineair, dus de claim dat er iets fout gaat met use after free is niet correct. Als je multi-threaded code had gehad was je verplicht geweest te voorkomen dat geheugen wordt aangesproken (mutex, etc.), en dan had je pas mogen vrijgeven na het laatste gebruik, dus na het sluiten van de laatste thread die er gebruik van maakt. Zulke situaties kunnen ook worden voorkomen door data te kopieren zodat er geen race conditie ontstaat.

[andru123]

Er zijn addons die dit type foutjes controleren, en warnings geven. Bijv. Resharper, VisualAssist, en de laatste versie van Visual Studio zelf. Als je gewend bent aan die addons dan denk je vaak niet over die kleine dingetjes. En mensen die met C# of Java werken, denken nooit over pointers per se.
Natuurlijk kan je een ref_ptr gebruiken, maar het kost je wel iets.
Ik gebruik altijd een ref_ptr of andere constructies, als het om generieke code gaat (de code die aangepast wordt door een contractor of een freshman). Alleen in kritische secties optimizieren wij, met een comment dabij om niet zonder review aan te passen.
Wat interessant is, hoe was die fout ontstaan in Firefox.

[Argantonis]

Tja maar feit blijft dat ook hele ervaren programmeurs die fouten blijven maken. Zijn geen juniors bij Mozilla lijkt me.

[mrmrmr]

De voorbeelden die Carnegie CERT geeft toont hoe complex het kan worden als je moeilijk te volgen functies/code gebruikt, terwijl het in lineaire code is te overzien. Volgbaarheid is belangrijk. Eenvoudig geschreven code is vaak ook nog sneller.

Als je hebt leren programmeren voor de security revolutie begin jaren '00 is de kans groot dat je verkeerde methodes hebt aangeleerd. Het kan een voordeel zijn als je een jonge programmeur bent met de juiste opleiding.

[Argantonis]

Tja, maar als je werkt bij een softwarebedrijf, en niet op een interne ontwikkelafdeling van een bedrijf waar software puur als ondersteuning dient of bij een uurtje-factuurtje-tent, dan maak je nou eenmaal complexe software met vaak stevige eisen aan performance. Sommige complexiteit is inherent. Elke bug op zich is achteraf gezien altijd te voorkomen geweest, maar mensen maken fouten, ook als ze slim zijn en goede practices gebruiken.

[Commandor1961]

met de update van addon zoom page we(https://addons.mozilla.org/nl/firefox/addon/zoom-page-we/) werkt de addon niet meer

Update 1 : werkt niet in firefox,werkt wel in edge,chrome
Update 2 : net nieuwe update van de addom nu werkt die wel weer goed

[Reactie gewijzigd door Commandor1961 op 25 juli 2024 19:09]

[Wouterie]

Ik schrok al! Maar het was al 'oud nieuws'