Mozilla Rolls Out Code Injection Attack Protection in Firefox

Mozilla rolled out protection measures to block code injection attacks in the Firefox web browser, with the attack surface being reduced by removing eval()-like functions and inline scripts occurrences.

“A proven effective way to counter code injection attacks is to reduce the attack surface by removing potentially dangerous artifacts in the codebase and hence hardening the code at various levels,” said the Mozilla Security Team today.

Inline scripts removal

Mozilla rewrote all inline event handler and moved inline JavaScript code to packaged files for all Firefox about:pages — a list of all 45 of them is available here — that are exposed to code injection attacks via inline scripts.

This type of pages are designed to provide users with a simple interface to inspect information related to Firefox’s inner workings, as is the case of the about:config page that “exposes an API to inspect and update preferences and settings.”

Given that about:pages use HTML and JavaScript just as regular web pages, potential attackers could take advantage of that to inject malicious scripts in the security context of the browser and thus being able to perform arbitrary actions on behalf of Firefox users.

“This allowed us to apply a strong Content Security Policy (CSP) such as ‘default-src chrome:’ which ensures that injected JavaScript code does not execute,” says Mozilla. “Instead JavaScript code only executes when loaded from a packaged resource using the internal chrome: protocol.”

By making it impossible to inject inline scripts within Firefox’s about:pages, Mozilla has created an efficient barrier against code injection attacks that could lead to arbitrary code execution by abusing this attack vector.

Runtime assertions to disallow eval() functions

“The JavaScript function eval(), along with the similar ‘new Function’ and ‘setTimeout()/setInterval()’, is a powerful yet dangerous tool. It parses and executes an arbitrary string in the same security context as itself,” also adds the Mozilla Security Team.

“This execution scheme conveniently allows executing code generated at runtime or stored in non-script locations like the Document-Object Model (DOM).” 

As Mozilla further details on its dev web docs, “eval() is a dangerous function, which executes the code it’s passed with the privileges of the caller. If you run eval() with a string that could be affected by a malicious party, you may end up running malicious code on the user’s machine with the permissions of your webpage / extension.”

To counter this issue, Mozilla has also rewritten “all use of ‘eval()’-like functions from system privileged contexts and from the parent process in the Firefox codebase” to curb the use of eval() and thus further reduce the attack surface.

Coding without eval()
Coding without eval()

Runtime assertions have also been added to Firefox’s codebase, a measure designed to disallow eval()-like functions in system-privileged script contexts.

Mozilla also discovered calls to eval() outside the Firefox codebase while working on removing all eval()-like functions. For instance, Firefox users would include eval() functions within customization files such as userChrome.js to customize Firefox at start up time.

Mozilla Security Team’s runtime checks validated that users did include evals in some of these customization files. To allow the users to customize their Firefox experience, Mozilla says that the browser will disable the “blocking mechanism and allow usage of eval().”

“Going forward, our introduced eval() assertions will continue to inform the Mozilla Security Team of yet unknown instances of eval() which we will closely audit and evaluate and restrict as we further harden the Firefox Security Landscape,” concludes Mozilla.