Microsoft, Mozilla fiksen vijf jaar oude Defender-bug die cpu-verbruik verhoogde

Microsoft heeft samen met Mozilla een bug in Windows Defender gerepareerd die ervoor kon zorgen dat Firefox voor een abnormaal hoog cpu-verbruik zorgde. Opvallend aan de bug was dat die al vijf jaar geleden werd aangedragen voor Windows 10.

De bug werd al in mei 2018 aangedragen in Mozilla's bugtracker Bugzilla. Daar werd het probleem benoemd voor toen nog Windows 10. De bug zorgde volgens de melder in sommige gevallen voor een hoog cpu-verbruik als Firefox werd geopend. Dat bleek door Windows Defender te komen.

Vorige maand ontdekten programmeurs bij Mozilla de oorzaak van het probleem. Dat lag in de Antimalware Service Executable van Windows Defender, die als Msmpeng.exe wordt uitgevoerd. Die executable spreekt het Event Tracing for Windows aan. Daardoor werden er tijdens het gebruik van Defender een hoog aantal VirtualProtect-calls aangemaakt waardoor het cpu-verbruik door het dak schoot. Dat zou veel vaker voorkomen dan bij Edge, Chrome en andere browsers. Mozilla wist de bug deels te mitigeren door JIT uit te schakelen in de browser, maar ging ook met Microsoft in gesprek om het probleem te repareren omdat dat uiteindelijk in Defender leek te zitten.

Microsoft heeft het probleem inmiddels opgelost. Vorige week werd dat in de engine van Defender bijgewerkt naar versie 1.1.20200.4 en inmiddels is dat in Platform-versie 4.18.2302.x ook gebeurd. Bij dat laatste wordt de detectie ook uitgerold naar tools zoals Defender Firewall, ATP of Endpoint. De fix werkt voor alle versies van Windows, dus niet alleen 11 maar ook 10 en zelfs 7 en 8.1.

Reacties (37)

[pkwarts]

Het is dus "Microsoft, Mozilla fiksen vijf jaar oude Defender-bug die cpu-verbruik verhoogd"

[atlaste]

Ik kan alleen uit eigen ervaring spreken. Mijn ervaring is met een aantal issues in de .NET GC waar ik een aantal keer een bug in heb gevonden. Specifiek, ik deed destijds wat vreemde tests, omdat ik gewoon wilde weten wat het gedrag was van het ding. In mijn geval leidde het regelmatig tot crashes en had ik de functionaliteit nodig voor een klant. Maar ik vermoed dat in dit geval het proces vergelijkbaar was. Ik zal een van de casussen beschrijven:

Als eerste in het proces deed ik net als zoveel mensen een bugreport. Het probleem met bug reports is alleen dat het meestal niet voldoende diepgang biedt, dus liet ik mijn contactgegevens achter en heb tot in detail beschreven hoe en wat. Een minimale test case lukte me niet, maar wel kon ik het reproduceren op een grote dataset met gegevens (onder NDA). In eerste instantie moet je dan door de eerste twee lijnen support heen komen, toelichten wat allemaal wel en niet kan (want NDA) en zo kom je bij de juiste persoon. In mijn geval was dat een van de core devs in het .net team, die uiteindelijk direct contact met me opnam, vooral omdat ik het probleem kon herproduceren en zij niet.

Deze man vroeg me vervolgens hele specifieke informatie zoals je van een goede developer verwacht. Denk aan specifieke registerwaarden via windbg, stacktraces met breakpoints op bep. adressen, etc. Ik leverde gewoon wat testwerk en de nodige detailinformatie. En daarna kwam hij vrij snel met een minimale testcase die het issue vlekkeloos reproduceerde. Een paar dagen volgde een hotfix die later is uitgerold via Windows Update.

Het proces werkte dus echt van "issue" naar "reproduceerbaar maken" naar "oplossen". Ik denk dat dat ook de juiste manier is van werken om te zorgen dat het opgelost blijft. Ik zou niet willen zeggen dat ik het probleem het opgelost, die credits behoren hun toe; wel heb ik ze geholpen in het reproduceerbaar maken.

Vwb. dit issue verwacht ik iets soortgelijks. Iedereen ziet het geheugen oplopen, maar Mozilla had blijkbaar specifiekere data over wanneer het probleem optreedt, waardoor die MS konden helpen het probleem goed te reproduceren. Als dat eenmaal het geval is kan je een unit test schrijven en het gestructureerd oplossen.

[Jerie]

Jullie hebben het samen opgelost. Jullie kregen er beide voor betaald, jij door jouw werkgever, hij door die van hem. Hij heeft het geïmplementeerd, jij hebt de bug gereport. Samen gedebugged. Bugs reporten is werken. Dat in onze wereld degene die de code schrijft de credits krijgt maar degene die de write-up doet, de bug report, QA tests doet, niet de credits krijgt, is m.i. fout. Het is een team effort. Al ligt het in de security wereld wel gebalanceerder. Maar dat komt omdat je mensen die kwetsbaarheden vinden een veer in de reet wilt steken zodat ze whitehat blijven ipv het foute pad op gaan.

[Reactie gewijzigd door Jerie op 22 juli 2024 17:07]

[The Zep Man]

Volgens mij lost Microsoft het probleem op nadat het aangedragen is door Mozilla. Iemand die een bug meldt is niet per se dezelfde partij die de bug oplost, ook al draagt de melder indirect wel bij aan de oplossing (geen melding, geen bug om op te lossen).

Het is dus "Microsoft lost vijf jaar oude Defender-bug op dankzij Mozilla".

[Reactie gewijzigd door The Zep Man op 22 juli 2024 17:07]

[MrFax]

Maar je weet niet hoeveel Mozilla heeft geholpen in het fixen. Ik vind dit wel op z'n plaats.

[Alex3]

"Verhoogt" dan toch.

[TijsZonderH]

Ja dat dekt de lading wel wat meer *extra kop koffie pakt*

[Postman]

Zou er dan ook "Microsoft en Mozilla" van maken i.p.v. "Microsoft, Mozilla". Nu lijkt het alsof er nog een derde partij aanwezig is, maar die ontbreekt in de opsomming.

[SeismicCharge]

Nou inderdaad. Die Amerikaanse gewoonte om ruimte in een gedrukte krantenkolom te sparen door een komma in plaats van 'and' te gebruiken heeft hier geen enkel nut en staat bovendien raar. Wat ga je doen met die uitgespaarde toetsaanslag?

[Bliksem B]

Ik snapte de titel al niet. Moest ik hem nou anders lezen 🤔?

[Postman]

Totaal offtopic, maar wel leerzaam. Wist niet dat het uit de US kwam. Nog even los van het feit dat op elk keyboard een & zit.

[Morress]

En goedemorgen

[MrMonkE]

Gebruiken jullie geen AI?
Kun je vragen: Maak deze titel maximaal 20 tekens lang. (Of hoe kort de titels -te kort - zijn)

edottttt: Ow, maar dat helpt natuurlijk niet in dit geval.

[Reactie gewijzigd door MrMonkE op 22 juli 2024 17:07]

[Qwilo]

Het is dan "Microsoft en Mozilla fiksen vijf jaar oude bug ...."

Tussen het een-na-laatste en laatste deel van een opsomming hoort een voegwoord te staan.

Thijs Hofmans en pkwarts maken een titel.

Thijs Hofmans, pkwarts en qwilo maken een titel.

[Alxndr]

Waarom de komma en niet gewoon 'en'? Of heb ik ook nog niet genoeg koffie gehad?

[kevlar01]

Ben benieuwd hoeveel onnodig stroomverbruik die bug in de afgelopen tijd heeft veroorzaakt

Blijkbaar was dit een lage prio bug die telkens onderaan de stapel terecht kwam....

[84hannes]

Blijkbaar was dit een lage prio bug die telkens onderaan de stapel terecht kwam....

Of een lastige bug omdat hij zich manifesteerde bij het draaien van Firefox, maar niet in Firefox zat. Het reproduceren kan verder gecompliceerd zijn omdat wellicht Windows Defender uit te schakelen is.

Wat zal Microsoft er van balen dat ze de gebruikerservaring van Firefox zo lang hebben getemperd.

[Jerie]

Wat zal Microsoft er van balen dat ze de gebruikerservaring van Firefox zo lang hebben getemperd.

Haha, exact. Firefox @ Windows, btw. Aan de andere kant heeft Firefox nu een laag marktpercentage. Daarnaast staat er ook 'in sommige gevallen' (lekker vaag).

Maar netjes is het niet. Al staat onderaan de bug report dat er meer werk nodig is om het euvel te voorkomen bij andere antivirus software.

[84hannes]

Aan de andere kant heeft Firefox nu een laag marktpercentage.

Je bedoelt dat Firefox zijn aandeel in deze vijf jaar van 11,3% naar 6,6% heeft zien dalen? Als ik Microsoft niet zou vertrouwen dan zou ik suggereren dat ze hun doel bereikt hebben. Gelukkig weten we allemaal dat Microsoft Open Source een goed hart toedraagt, maar nu echt.

[Maurits van Baerle]

Sinds Firefox een aantal jaar geleden standaard een hoop trackers en analytics is gaan blokkeren vertrouw ik de meetwaarden aan de kant van websites niet meer. Ik heb zelf een aantal websites waar ik toegang heb tot de analytics en waar mijn eigen bezoek met Firefox aan de site gewoon niet gemeten wordt.

Daar komt nog bovenop dat ik vermoed dat de gemiddelde Firefox gebruikers iets meer privacy bewust is dan de gemiddelde Chrome of Edge gebruiker en dus vaker iets als uBlock Origin of Ghostery zal draaien en dus ook niet opgepikt wordt door bijvoorbeeld Google Analytics of Matomo.

Kortom, tenzij je je server logs importeert voor analytics doeleinden zou ik als websitebeheerder er niet vanuit gaan dat je een goed beeld hebt van hoeveel van je bezoekers Firefox gebruiken.

[GertMenkel]

Met al die telemetrie die Microsoft verzamelt zou je toch wel verwachten dat al die trage VirtualProtect-calls op zouden vallen in de statistieken.

[bzuidgeest]

Ook bij andere browsers kwam het voor, maar veel minder staat er in het artikel. Dus niet alleen in FireFox.

cpu-verbruik door het dak schoot. Dat zou veel vaker voorkomen dan bij Edge, Chrome en andere browsers.

[Anoniem: 1849202]

Gezien het enkel bij het opstarten voorkwam en niet bij verder gebruik van de browser is het denk ik niet zo opgevallen, sterker nog dit is voor mij als Firefox-gebruiker nieuws. Het is mij namelijk nooit opgevallen dat het CPU-gebruik hoog is bij opstarten omdat dit namelijk maar enkele tellen duurt.

Het is uiteindelijk voor een browser-developer, belangrijker dat een browser presteert bij het uitvoeren van diens basistaken, namelijk browsen en het goed weergeven van de aangeboden content op het web en dat doet Firefox tot op heden naar voldoening.

[Jerie]

Gezien het enkel bij het opstarten voorkwam en niet bij verder gebruik van de browser is het denk ik niet zo opgevallen, sterker nog dit is voor mij als Firefox-gebruiker nieuws. Het is mij namelijk nooit opgevallen dat het CPU-gebruik hoog is bij opstarten omdat dit namelijk maar enkele tellen duurt.

Als je flink wat tabs open hebt staan, zal-ie dat met SQL (sqlite) aanspreken en moeten openen. Dat duurt even. Ik snap nu wel waarom Firefox trager opstart op Windows dan op Linux/macOS.

[Anoniem: 316512]

Ik ben benieuwd hoeveel stroomverbruik het kost om Firefox te gebruiken in plaats van Chrome of zo.

[Aldy]

Onnodig stroomverbruik en vastlopen. Gelukkig hebben ze het probleem bij Mozilla gevonden zodat Microsoft het alleen nog maar hoefde op te lossen. Denk dat het bij open source iets sneller was opgelost.

[dasiro]

Los van het feit dat het fenomeen zich al 5 jaar voor doet is de oorzaak slechts een maand geleden gevonden. Hoe het proces binnen Microsoft verlopen is (start/oorzaak/oplossing) is niet bekend.

Af en toe worden er dingen opgelost die lang aanslepen, dat wil daarom niet zeggen dat er ook al zo lang aan gewerkt is, maar vaker wel dan niet dat er dan pas in-depth naar is gekeken geweest door de juiste mensen met het juiste inzicht.

[Anoniem: 454358]

Of een geval van, dat ligt toch niet aan ons, jullie pakket zal wel brak zijn .

[Get!em]

Ik ben benieuwd of dit het algehele verbruik wat omlaag brengt. Ik had/heb flink last van een hoog CPU verbruik met firefox en defender, vooral bij dynamische websites met veel data inladen tijdens gebruik (zoals google maps).
Op de i7 11th ging hij hier regelmatig naar 80% (Defender).

[LieveGeit]

Heb zelf veel problemen met Defender sinds build 22621 van 22H2 (WIN11) en vele anderen ook als ik ga Googlen. Op mijn oude PC nog WIN10 22H2 en daar geen problemen met Defender.
Hij zei de hele tijd "Unknown" bij alle onderdelen van Windows Security
Omdat ik mij zorgen maakte dat ik wellicht gehackt werd heb ik WIN11 geherinstalleerd maar nu zegt hij "Standard hardware security not supported" onder "Device Protection" ondanks dat HVCI (Hypervisor-Protected Code Integrity), Secure Boot, DEP (Data Execution Prevention), Intel Virtualization, UEFI Boot, TPM (2.0) allemaal zijn ingeschakeld en ik op Alder Lake (12e gen) zit
Ook staat er een uitroepteken bij het icoontje van Defender maar ik kan dit niet fixen want "App & Browser control" is afwezig en daar zijn "Actions Recommended"

[Mitsuko]

Nog wat verdere details:

• De oplossing vermindert de overhead met 75% en dit helpt alle applicaties die gebruik maken van VirtualProtect (niet alleen Firefox, maar Firefox maakt er relatief veel gebruik van)
• Chrome beperkt het aantal functieaanroepen door compilatie in batches uit te voeren - dit zou Firefox ook kunnen gaan doen om de overhead nog verder te beperken.
• Chrome gebruikt daarnaast VirtualAlloc ipv. VirtualProtect om bestaande pages een andere bescherming te geven - deze functie heeft minder overhead, waarschijnlijk omdat het de oude bescherming niet terug geeft (en er dus minder te controleren is). Dit kan Firefox misschien ook doen (waarschijnlijk in bug 1823634).

[Redsfan]

Schandalig dat MS daar 5 jaar voor nodig had !! haha
Wel geen last van gehad, ik gebruik geen defender en geen firefox

[Reactie gewijzigd door Redsfan op 22 juli 2024 17:07]

[BliebBlop]

Betreft dit deze bug?

https://www.techpowerup.c...ance-we-have-the-fix?cp=4

Zo ja, kan dan dus het programma Counter Control van TechPowerup naar de prullenbak?

[E.Bouma]

Net de laatste Windows updates geïnstalleerd, maar mpengine.dll van Windows Defender is NIET bijgewerkt naar versie 1.1.20200.4.
Heb nog steeds 1.1.17700.4 van 15-12-2020, dus NIKS gefixed.
"Vorige week werd dat in de engine van Defender bijgewerkt naar versie 1.1.20200.4" klopt dus niet.

Is fijn
Update werkt NIET als je andere beveiligingssoftware (ESET) hebt geïnstalleerd...

[Reactie gewijzigd door E.Bouma op 22 juli 2024 17:07]

[TvdD]

Gelukkig dat het is opgelost. heb er zelf alleen weinig last van gehad.

[Reactie gewijzigd door TvdD op 22 juli 2024 17:07]