zlacker

>>mconle+(OP)
TL;DR: Windows Defender had a bug that made certain system calls expensive on CPU cycles when Defender's Real-time Protection feature is enabled. After discovery, Mozilla reported this issue to Microsoft. Microsoft is releasing a patch that should result in lower CPU usage when using Firefox on sites like YouTube (a ~75% CPU usage reduction was noted when browsing YouTube in Firefox with the fixed version of Defender).

It seems like the HN submission form truncated the # from the end of the URL I linked to, which linked to the relevant comment. I'll try that here:

https://bugzilla.mozilla.org/show_bug.cgi?id=1441918#c82

and

https://bugzilla.mozilla.org/show_bug.cgi?id=1441918#c91

>>mconle+h3
It's not just mozilla, been working defender issues for the last few years on thousands of windows vm's. Mostly due to the enabling the more intensive heuristic real time engine and they have different code bases depending on versions installed on different windows builds, and patching does seem to trigger it. For months we had issues where we couldnt log into some vm's due to high cpu for defender, and had to bounce the vm and apply a temp defender fix.

I think its a growing issue, as they mature/migrate their older code base, issues become less frequent.

>>IronWo+ib
I have malwarebytes premium and defender CPU usage is nearly 100% at times bringin Firefox to a halt. Chrome works fine..I've been blaming Firefox so far.

>>psychp+Nc
In my experience (as a former Firefox dev), antivirus / antimalware software are really poorly behaved. They tend to:

- require admin rights (which means that if they have vulnerabilities, it can take control of the entire machine, even if Firefox itself is sanboxed);

- monkey-patch the Firefox executable in memory, which works (when it does) as long as the version of the software tracks closely the version of Firefox, which may or may not be the case;

- ... and also decreases the memory-safety of Firefox, which makes it easier to pwn;

- ... and also makes the crash reports unreliable;

- install encryption certificates that are actually less trustworthy than Mozilla's, hence decreasing the security of https;

- block Firefox and add-on security updates, also decreasing security;

- install privileged add-ons, many of which are easy to exploit from any webpage;

- ...

Part of the work on Crash Scene Investigations was attempting to determine whether the crash was in Firefox or in code or in some bogus foreign code. Depressingly often, it was the latter.

In your case, it's entirely possible that malwarebytes was simply untested on Firefox.

>>Yoric+7q
I had always assumed that one application could not touch the memory of another application. Does running as Admin allow breaking this boundary?

>>jbritt+sJ
Yes, in general on Windows processes with higher privilege levels can get access to read/write another processes memory, or even inject code into them. And even Admin-level processes can still be broken into by something running as a service with even more elevated privileges like NT AUTHORITY\SYSTEM.

This has long been a leaky part of Windows security. If your malware can get its code running inside a highly privileged service or process, it can do more or less whatever it wants to the rest of the system. But even when not used for nefarious purposes, it is still an extremely dangerous capability in that it can be very easy to create problems .

>>genoci+xX
Anything you run as your user can be accessed.