HTML Injection in resource:// scheme on Fenix error pages
Categories
(Fenix :: Browser Engine, defect, P5)
Tracking
(Not tracked)
People
(Reporter: telavivkeller, Unassigned)
References
(Depends on 1 open bug, )
Details
(Keywords: csectype-spoof, reporter-external, sec-low, Whiteboard: [reporter-external] [client-bounty-form] [verif?])
Steps To Reproduce:
- Download the https://github.com/mozilla/gecko-dev/tree/2537e5eaafaab9a7ef6be5cfc8e9b1e2c747fdfd/mobile/android/fenix/app/src/main/assets/ folder
- Edit the
high_risk_error_pages.html
and remove the CSP meta tag
This is because this page usually runs of the
resource:
scheme, and we will be hosting it locally
- Open
high_risk_error_pages.html?&title=<HTML>
, where<HTML>
is any HTML to inject.
Note: While XSS will be possible, in production, with the CSP tag, it will not, so this is only HTML injection
A similar process can be used on low_and_medium_risk_error_pages.html
.
Impact
An attacker can spoof content on a official FireFox page, which can help with various other attacks. If the CSP header is removed in the future, this can also become XSS.
Comment 1•10 months ago
|
||
I'm a bit confused about the STR here.
Are you able to open these pages from the web (using resource:
URLs) while injecting arbitrary URL params?
If not, how would this be exploited in practice? If you can convince the user to download files and modify them, there are obviously easier ways to inject content...
Updated•10 months ago
|
Reporter | ||
Comment 2•10 months ago
•
|
||
Sorry, this can be exploited via a resource url, that URL is the Reference URL on this report. I thought I included in also in the comment.
resource://android/assets/low_and_medium_risk_error_pages.html?&description=%3Ch1%3EHTML%3C%2Fh1%3E
Reporter | ||
Comment 3•10 months ago
|
||
The only reason you would remove the CSP tag is that, when downloading directly from GitHub, the CSP will block the scripts from executing, as it wouldn’t be on the resource:// scheme, but rather the file:// scheme
Reporter | ||
Updated•10 months ago
|
Comment 4•10 months ago
|
||
This is a bug filed against "Fenix", not "the Fenix repo". Is there a bug in Fenix? resource:// urls won't open on a link click, will throw an error if you try to navigate in script, and you can't paste it into the URL bar.
Reporter | ||
Comment 5•10 months ago
|
||
The bug in Fenix are the resource:// URLs. Despite the current measures in place to prevent access to them, vulnerabilities within them should still be resolved.
Comment 6•10 months ago
|
||
I thought we already had a (likely public) bug on file about the need to stop relying on query params for messaging on network error pages, but I cannot find one. Valentin, am I just not looking in the right places?
Although in general I think we are interested in e.g. sandbox escape type bugs where we assume that one or more layers of our defence-in-depth mechanisms are breached, this seems... pretty far-fetched? To get to executing script you'd need to both bypass the CSP and bypass our link/navigation protections. I'm not sure I see what you would achieve with "only" markup injection (without a CSP bypass). This wouldn't run any script or inline styles, so the best you could try to do is... try to convince the user to click some of the otherwise already interactive elements on the page, using only plain HTML styled using the CSS that's already there? Do you have a concrete example of how this would lead to user harm?
Comment 7•10 months ago
|
||
I guess bug 1196267 fits the bill. Although that is about the desktop page, to fix this bug I suspect we would need to change both toolkit
error pages, the mobile ones, and the underlying docshell code. Perhaps a dep would be more appropriate than a dupe, even if the root problem is very much interrelated.
Also, at least on desktop these about
pages are relatively unprivileged (a bit similar to about:blank
) as yet another layer of defence in depth - so even if you hypothetically could run script, it couldn't actually do very much. I don't know to what degree this is true on mobile.
Reporter | ||
Comment 8•10 months ago
|
||
Yeah, you're right about the risk being low, but it's still something that needs fixing, even if it's not urgent.
Comment 9•10 months ago
|
||
This is definitely not a duplicate of the desktop bug because there will have to be mobile-only changes in mobile-only resources and code. I'll make it "depend on" for now because we may need the docShell changes first, but it might be completely independent
This unfortunately does not qualify for our Bug Bounty program. If you can find an attack that would let you use this against users then it could, although most likely whatever you found and used would be a more severe security bug in its own right.
Updated•10 months ago
|
Updated•10 months ago
|
Updated•8 months ago
|
Description
•