Open Bug 1889942 Opened 10 months ago Updated 4 months ago

HTML Injection in resource:// scheme on Fenix error pages

Categories

(Fenix :: Browser Engine, defect, P5)

defect

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:

  1. Download the https://github.com/mozilla/gecko-dev/tree/2537e5eaafaab9a7ef6be5cfc8e9b1e2c747fdfd/mobile/android/fenix/app/src/main/assets/ folder
  2. 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

  1. 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.

Flags: sec-bounty?

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...

Group: firefox-core-security → mobile-core-security
Component: Security → General
Flags: needinfo?(telavivkeller)
Product: Firefox → Fenix
OS: Unspecified → All
Hardware: Unspecified → All
Summary: HTML Inject in resource:// scheme → HTML Inject in resource:// scheme on Fenix error pages

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

Flags: needinfo?(telavivkeller)

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

Summary: HTML Inject in resource:// scheme on Fenix error pages → HTML Injection in resource:// scheme on Fenix error pages

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.

Flags: needinfo?(telavivkeller)

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.

Flags: needinfo?(telavivkeller)

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?

Flags: needinfo?(valentin.gosu)
Flags: needinfo?(telavivkeller)

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.

Flags: needinfo?(valentin.gosu)

Yeah, you're right about the risk being low, but it's still something that needs fixing, even if it's not urgent.

Flags: needinfo?(telavivkeller)

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.

Group: mobile-core-security
Status: UNCONFIRMED → NEW
Depends on: 1196267
Ever confirmed: true
Flags: sec-bounty? → sec-bounty-
See Also: → 1196267
Component: General → Browser Engine
Severity: -- → S3
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.