https://www.mozilla.org/en-US/security/advisories/mfsa2018-11/#CVE-2018-5175
A mechanism to bypass Content Security Policy (CSP) protections on sites that have a script-src policy of 'strict-dynamic'. If a target website contains an HTML injection flaw an attacker could inject a reference to a copy of the require.js library that is part of Firefox’s Developer Tools, and then use a known technique using that library to bypass the CSP restrictions on executing injected scripts.
What is the "strict-dynamic"?
maybe you should read CSP spec :) https://www.w3.org/TR/CSP3/#strict-dynamic-usage
But for practicing writing in English, I'll explain about strict-dynamic. If you know about strict-dynamic, you don't have to read this section.
The well-known CSP restricts the loading of resources by whitelisting domains.
For example, the following CSP setting allows to load JavaScript only from its own origin and trusted.example.com:
Content-Security-Policy: script-src 'self' trusted.example.com
Thanks to this CSP, even if the page has an XSS vulnerability, the page is prevented to execute JavaScript from the inline scripts or JavaScript file of evil.example.org. It looks safe enough, however, if trusted.example.com has any scripts for bypassing CSP, it is still possible to execute JavaScript. More specifically, if trusted.example.com has a JSONP endpoint, it might be bypassed, like this:
<script src="//trusted.example.com/jsonp?callback=alert(1)//"></script>
If this endpoint reflects the user input passed to the callback parameter to the callback function name directly, it can be used as an arbitrary script as follows:
alert(1)//({});
In additon, it is known that AngularJS also can be used for bypassing CSP. This bypass possibility becomes more realistic, especially if domains hosting many JavaScript files, such as CDN, are allowed.
That way, in the whitelist, it is sometimes difficult to operate the CSP safely. To resolve this problem, strict-dynamic was designed. This is the example of usage:
Content-Security-Policy: script-src 'nonce-secret' 'strict-dynamic'
This CSP means that the whitelist will be disabled and only scripts having the "secret" string in the nonce attribute will load.
<!-- This will load -->
<script src="//example.com/assets/A.js" nonce="secret"></script>
<!-- This will not load -->
<script src="//example.com/assets/B.js"></script>
The A.js might want to load and use another JavaScript. To allow this, the CSP spec permits to load without the proper nonce attribute if the js having the proper nonce loads an another js in specific conditions. With the word written in the spec, the non-"parser-inserted" script element can be allowed to execute JavaScript.
Below are concrete examples of what type of JavaScript are permitted:
/* A.js */
//This will load
var script=document.createElement('script');
script.src='//example.org/dependency.js';
document.body.appendChild(script);
//This will not load
document.write("<scr"+"ipt src='//example.org/dependency.js'></scr"+"ipt>");
When loading using
createElement(), it's a non-"parser-inserted" script element and the loading is allowed. On the other hand, when loading using document.write(), it is a "parser-inserted" script element and it is not loaded.
Up to this point, I explained about strict-dynamic roughly.
By the way, the strcit-dynamic is bypassable in some cases. In the next, I'll introduce about a known strict-dynamic bypass.
Known strict-dynamic bypass
It is known that strict-dynamic also can be bypassed if a specific library is used in the target page.
By Google's Sebastian Lekies, Eduardo Vela Nava, and Krzysztof Kotowicz, affected libraries are listed here:
Let's look into the strict-dynamic bypass of require.js on this list.
Let's say the target page uses CSP with strict-dynamic, loads require.js and has a simple XSS. In this situation, if the following script element is inserted, an attacker can execute arbitrary JavaScript without the proper nonce.
<meta http-equiv="Content-Security-Policy" content="default-src 'none';script-src 'nonce-secret' 'strict-dynamic'">
<!-- XSS START -->
<script data-main="data:,alert(1)"></script>
<!-- XSS END -->
<script nonce="secret" src="require.js"></script>
When the require.js finds a script element with a
data-main attribute, it loads a script specified in the data-main attribute from the equivalent code as below:var node = document.createElement('script');As described before, the strict-dynamic is allowed to load JavaScript from
node.src = 'data:,alert(1)';
document.head.appendChild(node);
createElement() without the proper nonce.That way, you can bypass the CSP strict-dynamic in some cases using the behavior of already loaded JavaScript code.
Firefox's vulnerability was caused by this behavior of require.js.
In the next section, I'll explain the vulnerability.
Universal strict-dynamic bypass(CVE-2018-5175)
Firefox implements some browser features using legacy extensions. The legacy extensions means XUL/XPCOM-based extensions that was removed in Firefox 57, not WebExtensions. Even on the latest Firefox 60, the browser internals still uses this mechanism.
In this bypass, we use a resource of the legacy extension which is used in browser internals. In WebExtensions, by setting a web_accessible_resources key in the manifest, the listed resources become accessible from any web pages. The legacy extension has a similar option named contentaccessible flag. In this bypass, it could be used for bypassing CSP because a require.js of browser's internal resource was accessible from any web pages due to the
Let's look into the manifest. If you are using 64bit Firefox on Windows, you can see the manifest from the following URL:
jar:file:///C:/Program%20Files%20(x86)/Mozilla%20Firefox/browser/omni.ja!/chrome/chrome.manifest
content branding browser/content/branding/ contentaccessible=yes
content browser browser/content/browser/ contentaccessible=yes
skin browser classic/1.0 browser/skin/classic/browser/
skin communicator classic/1.0 browser/skin/classic/communicator/
content webide webide/content/
skin webide classic/1.0 webide/skin/
content devtools-shim devtools-shim/content/
content devtools devtools/content/
skin devtools classic/1.0 devtools/skin/
locale branding ja ja/locale/branding/
locale browser ja ja/locale/browser/
locale browser-region ja ja/locale/browser-region/
locale devtools ja ja/locale/ja/devtools/client/
locale devtools-shared ja ja/locale/ja/devtools/shared/
locale devtools-shim ja ja/locale/ja/devtools/shim/
locale pdf.js ja ja/locale/pdfviewer/
overlay chrome://browser/content/browser.xul chrome://browser/content/report-phishing-overlay.xul
overlay chrome://browser/content/places/places.xul chrome://browser/content/places/downloadsViewOverlay.xul
overlay chrome://global/content/viewPartialSource.xul chrome://browser/content/viewSourceOverlay.xul
overlay chrome://global/content/viewSource.xul chrome://browser/content/viewSourceOverlay.xul
override chrome://global/content/license.html chrome://browser/content/license.html
override chrome://global/content/netError.xhtml chrome://browser/content/aboutNetError.xhtml
override chrome://global/locale/appstrings.properties chrome://browser/locale/appstrings.properties
override chrome://global/locale/netError.dtd chrome://browser/locale/netError.dtd
override chrome://mozapps/locale/downloads/settingsChange.dtd chrome://browser/locale/downloads/settingsChange.dtd
resource search-plugins chrome://browser/locale/searchplugins/
resource usercontext-content browser/content/ contentaccessible=yes
resource pdf.js pdfjs/content/
resource devtools devtools/modules/devtools/
resource devtools-client-jsonview resource://devtools/client/jsonview/ contentaccessible=yes
resource devtools-client-shared resource://devtools/client/shared/ contentaccessible=yes
The yellow part is the part that makes the file accessible from any web sites. These two lines are for creating a resource: URI. The
resource devtools devtools/modules/devtools/ of first line is mapping devtools/modules/devtools/ directory ( It exists on jar:file:///C:/Program%20Files%20(x86)/Mozilla%20Firefox/browser/omni.ja!/chrome/devtools/modules/devtools/ ) to resource://devtools/ .
We can now access files under the directory by opening resource://devtools/ using Firefox. Likewise, the next line is mapping to resource://devtools-client-jsonview/. This URL becomes web-accessible by the contentaccessible=yes flag and we can now load the files placed under this directory from any web pages.
This directory has a require.js which is used for bypassing CSP. Just loading this require.js to the page where the CSP strict-dynamic is used, you can bypass strict-dynamic.
<meta http-equiv="Content-Security-Policy" content="default-src 'none';script-src 'nonce-secret' 'strict-dynamic'">
<!-- XSS START -->
<script data-main="data:,alert(1)"></script>
<script src="resource://devtools-client-jsonview/lib/require.js"></script>
<!-- XSS END -->
From this code, data: URL will be loaded as a JavaScript resource and it will pop up an alert dialog.
You might think, "Hmm, why is the require.js loaded? It should be blocked by CSP because the script element does not have the proper nonce."
Actually, no matter how strictly you set CSP rules, the web-accessible resources of the extension is loaded ignoring the CSP. This behavior is mentioned in the CSP spec:
Policy enforced on a resource SHOULD NOT interfere with the operation of user-agent features like addons, extensions, or bookmarklets. These kinds of features generally advance the user’s priority over page authors, as espoused in [HTML-DESIGN].
Firefox's resource: URI also had this rule. Thanks to this, users can use the extension's features as expected even on the page where the CSP is set, but on the other hand, this privilege sometimes can be used for bypassing the CSP, like this bug's case.
Of course, this issue is not limited to browser internal resources. Even on general browser extensions, the same thing happens if there are web-accessible resources that can be used for bypassing CSP.
It seems that Firefox folks fixed this bug by applying page's CSP to the resource: URI.
In the end of article
I wrote about a CSP strict-dynamic bypass vulnerability of Firefox.
FYI, I found this issue when I was looking for another solution of Cure53 CNY XSS Challenge 2018's third level which I made. In this challenge, I used another trick to bypass strict-dynamic. Please check it if you are interested.
Also, I created a different version of this XSS Challenge and I'm still waiting your answer :)
Lastly, I'd like to thank Google's research which made me notice this bug. Thank you!
