Firefox will block DLL Injections
Mozilla Firefox will soon block the injection of DLLs by antivirus applications and other third-party programs in an effort to improve stability, security, and privacy.
Antivirus applications on Windows and other third-party applications, e.g. other security software or PDF tools, may inject DLLs in the browser. These injections are known to cause stability issues for users.
Mozilla follows Google which started to block third-party code injections in Google Chrome in 2018. Google discovered that Chrome installations with third-party DLL injection crashed 15% more than Chrome installations without.
Mozilla started to investigate options to disable DLL injections in Firefox in the fourth quarter of 2016 but things picked up speed only recently.
Update: it appears that Firefox is using a DLL blocklist to prevent problematic DLLs from being injected in the browser. End
Firefox Nightly, the cutting edge version of the Firefox browser, blocks DLL injections already. The feature will be integrated in Beta and Release versions of the Firefox browser when they hit version 66.
Firefox Beta will hit version 66 on January 29, 2019, and Firefox Stable version 66 on March 19, 2019 according to the release schedule.
How do you know whether the protective feature is enabled already? That's easy. Just open about:support in the browser's address bar and check the Launcher Process listing near the top.
If it states enabled it is active; if it states disabled or is not present, it is inactive.
You may check the internal page about:third-party to find out which third-party DLL files are loaded in Firefox.
Firefox users can disable the feature currently and it is likely that the turn-off option remains a feature in Beta and Stable as well.
Go to about:config and search for browser.launcherProcess.enabled to display the preference in Firefox. Note that the link returns the preference only if it exists.
Double-click on it to set it to True or False. True means that the launcher process is enabled, False that it is disabled. Firefox blocks DLL Injections by third-party applications if the preference is set to true.
Firefox users (and Chrome users) may experience issues with their browsers or applications that attempt to inject DLLs into the browsers. Third-party developers may need to update their applications to remove the DLL injecting components from the applications or exclude browsers that block these attempt anyway.
DLL injections have always caused stability issues on Windows; Google discovered a 15% more crashes in Chrome browsers with DLL injections than without. Mozilla did not reveal any statistics but it is likely that the figure is in the same region. (via Techdows)
Fine by me. Most AV applications are bad for your computer, anyway.
Mostly when multiple iterations are present. It worked and was required in the mid 2000’s to have an A/V and a seperate spyware/malware tool, but they blurred the lines and there’s no such thing, as a malware/spyware tool that doesn’t think it’s also an A/V.
Freakin browsers are also getting annoying, mining software downloads being blocked due to “danger”, so much, I have to wget them in my vps shell, :rolls eyes:
The best thing to do to check for malware/viruses on a windows partition? Boot up with a Linux distro on a usb or disc and then run ClamAV over the windows partition…you’ll find things others can’t find due to windows locking folders and “C:” …but of course that’s a feature, not a bug..heh.
Great addition for privacy and control over the browser !
I wonder what this bodes for programs, AV or otherwise, for Firefox users. It’s been my go-to browser since it was Phoenix.
Drilling 64.0.2 under Win7 with Sysinternals’ Process Explorer, current injections are for QFX KeyScrambler, Malwarebytes Anti-Exploit and i7-3770K Graphics.
The graphics drivers, Shader Compiler (for acceleration) and the User Mode itself, would be a critical cause for concern.
As well, the other two have presented stable and competent service for countless users for many years.
I’m trying to envision this policy without some kind of certification construct from Mozilla to allow for such programs or an “under the hood” method for power users to do so. Other than a false setting for the pref. But if that’s what it takes, false it is.
No it will not.
This feature has been in the works for months. It is not slated for a wide release. It’s WIP. The Indian blog is wrong. Check the bug Moz bug tracker.
Stability is one thing (depends on both FF and the 3rd-party product), but how preventing ALL security software to work with Firefox is supposed to improve security is beyond me… unless Mozilla plans to turn Firefox into an A/V suite as well?
What are all these deadly viruses and security threats you think you are experiencing with Firefox? LOL All you need is uBlock and if you’re extra paranoid NoScript. There are zero exploitable vulnerabilities in Firefox with those two extensions running. Future changes will make Firefox even more secure. Most attacks happened through Microsoft’s software and Flash, not Firefox.
With only the great Gorhill extensions in nightmare mode and FF up to date you’re not totally protected, las year I’ve had two malware download attempts blocked by EIS (ESET) while visiting an hijacked tech site, google safecensorship demonstrated to be totally useless and the attempted attack was no flash (never installed) or MS Win fault.
@Anonymous, first try to fully understand a comment then LOL. I am not experiencing “deadly viruses and security threats”. Security is about prevention. A good 3rd-party security product offers a maintained and up to date threat database that not always free filter lists and extensions like uBlock will be able to match. That’s not to say they are not good.
What’s more, Google/Mozilla have indicated that content-blocking extensions (like uBlock etc.) will be restricted too even more, in the future. I’d love to see your updated LOL comment, then.
Leaving everything (including non browsing-related functions) up to a browser riddled with corporate restrictions is my concern.
@Anonymous: “There are zero exploitable vulnerabilities in Firefox with those two extensions running.”
There is no such thing as complex network-facing software with “zero exploitable vulnerabilities”, period.
“Google discovered a 15% more crashes in Chrome browsers with DLL injections than without.”
But what about the worst avoided by wise DLL injections?
As @Alex mentioned it, above, blocking worthy DLL injections performed by security software logically puts a new responsibility on the browser’s shoulders, one of those which is not really that of a browser : combating the Wild Wild Web’s villains’ viruses and other petty acts.
I have no idea about the balance result. Curious.
It would be good if they named it something more understandable and useful than “Launcher process”.
This is not strictly for antivirus but also for download managers. Now that Flashgot is impossible to create in WebExtension, the only thing to forward the download is by using the DLL extension.
This is truly the end of Firefox.
I think this browser crashing problem occurs mainly because ignorant users enable the AV features that filter or shield their web-browsing, eg from visiting known harmful websites. These extra AV features are mostly redundant because browsers and search engines themselves filter out known harmful websites.
Web-surfers are supposed to use a non-Admin account, be vigilant and careful about visiting websites, downloading files, opening email file attachments, opening links, etc. AV programs do not prevent user gullibility, foolishness, carelessness, greed(eg downloading pirated stuffs), etc.
@Anonymous, and allow Google/Mozilla to spy on you exclusively. Great advice. Also, break half the Internet with turning JS off. Brilliant.
@Alex: “break half the Internet with turning JS off. Brilliant.”
By “internet”, I think you mean “the web”.
I keep JS turned off for the most part. It doesn’t break half the web, really. And, mostly, the parts of the web that do break also happen to be the parts that are easy for me to do without. I do have to make a few exceptions — but even then, I only enable specific JS scripts, not JS in general.
Edge blocks DLL injections.
I use KAV and disabled code injections into Chrome.
AV programs should not be messing with the internals of browsers since most browsers, search engines and email service providers already filter/shield against harmful websites/links.
I use Norton Security Suite version 18.104.22.168 and Malwarebytes version 22.214.171.1242.
Using Process Explorer > View > Lower Pane View > DLLs, I observe the following in the main process of the 64-bit version of Firefox 64.0:
mbae64.dll – Malwarebytes Anti-Exploit (Malwarebytes Corporation)
ccLib.dll – Symantec Library (Symantec Corporation) (also injected into explorer.exe)
ccVrTrst.dll- Symantec Trust Validation Engine 64 bit (Symantec Corporation) (also injected into explorer.exe)
EFACli64.dll – Symantec Extended File Attributes (Symantec Corporation) (also injected into explorer.exe)
spifc.dll – Symantec Platform Component Library (Symantec Corporation)
IPSEng64.dll – IPS Script Engine DLL (Symantec Corporation)
The Malwarebytes DLL injection can be mitigated (but you lose Malwarebytes protection) by toggling the “Mozilla Firefox (and add-ons)” Protection button to Off from Malwarebytes Main Menu > Settings > Protection tab > Real-Time Protection > Manage Protected Applications. Firefox does not need to be restarted – you can watch the DLL being removed/added in real-time via the Process Explorer display.
Injection of the Symantec IPS Script Engine DLL apparently started in August 2014 as a replacement for the Norton Vulnerability Protection Browser Helper Object (BHO). See https://community.norton.com/en/comment/7013821#comment-7013821
Turning off Norton’s SONAR Protection, Auto-Protect, and Boot Time Protection for 15 minutes did not dynamically remove their injected DLLs.
I hope that Symantec provides a way for users to control injection of DLLs into Firefox (or as stated in the article “exclude browsers that block these attempt anyway”), or that Mozilla provides a whitelisting capability, so that both products can peacefully co-exist and so users don’t have to switch browsers and/or anti-virus products.
Bloody authoritarians! I’ll inject whatever I damn well please, it’s MY computer, not yours!
There goes the deplatformingfox again. Now they’re blocking DLL injections! cEnSoRsHiP!
You said that if the setting browser.launcherProcess.enabled is set to true in about:config DLL injections will be blocked. We’re now in 2022 and mbae64.dll is still visible in Firefox 103.2 Here’s a pix of it.
I ran tthe Refresh option in FF to try to remove it, but it kept returning and decided to uninstall / reinstall FF, but it’s still there.
I’ve partly caused this myself by restoring my Windows 8.1 machine to a system image I created at the beginning of May this year. Malwarebytes Browser Guard was installed around that time, but due to stability issues, I removed. But re-imaging the system has introduced it again.
I mailed Malwarebytes support about this issue last week, but they seem to be ignoring me in spite of the fact I have a Premium license.
Do you happen to know how to remove it?
Never Mind!! I found it in the Mbam —> Security —> Managed Applications. And it’s gone from Firefox now. Phew!!
I don’t know that, but it appears that Mozilla is using a DLL blocklist and not completely blocking all third-party DLLs.
Here’s a pix of where the option to disable injection of dll’s in applications can be found in Malwarebytes Premium (just in case somebody else experiences the same problem)
P.S. Apologies for any inconvenience caused.
Firefox 103.0.2 : ‘Launcher Process’ appears as ‘Enabled’ in about;support but its ‘browser.launcherProcess.enabled’ pref is no longer available in about:config. Could be a hidden pref but creating that pref (boolean) and setting it to ‘false’ did not modify its ‘Enabled’ status in about:support (unless it would be after restarting Firefox, which I haven’t tested). Should it be modifiable that I certainly wouldn’t disable it.
TelIV’s comment above is a good reminder of the utility of Firefox’s ‘about:third-party’ module : empty here. Sometimes we want neither a half-empty nor half-full glass, but a fully-empty one (can you dig that sophisticated humor?!).
My mistake : ‘browser.launcherProcess.enabled’ pref does appear in about:config but it is set by Firefox on start. No possible modification unless maybe to lock that pref to ‘false’ with Firefox’s Autoconfig, but I doubt it’d be wise should it be possible.
My double mistake, terribly sorry.
The ‘browser.launcherProcess.enabled’ pref does appear in about:config
– A manual ‘Reset’ removes it from about:config but it reappears after Firefox restart
– Switching the pref (true/false) is effective only after a Firefox restart
– If ‘browser.launcherProcess.enabled’ is disabled by the user when natively enabled, then ‘Launcher Process’ in about:support will state : ‘Disabled forcibly’
I got confused because the pref appears as modified in about:config …
Better late than never. Sorry for three comments when one should have made it. I’m not in love presently so that won’t explain my goofs.