1863832 - (CVE-2024-10474) Don't allow web content to open firefox-focus: URLs

Status: RESOLVED FIXED

(Focus :: Security: iOS, defect)

Description

[James Lee]

We are able to launch firefox-focus:// URI internally and when this is used together with URI Scheme Origin Spoof issue which I'll describe it below, allows to achieve Full UXSS.

We can request firefox-focus:// internally on any target origin using window.open() with setTimeout().

In summary, we are opening target origin with window.open() and running firefox-focus:// internally.

This possibly might look similar to https://bugzilla.mozilla.org/show_bug.cgi?id=1863831 but there are clear differences between these two.

1. We are using URI Origin spoof to achieve Full UXSS without "This is all possible (Full UXSS) because iOS Firefox Focus allows silent background navigation while user left the browser."

2. Any other browser doesn't allow to run its own URI Scheme on browser itself internally (e.g. googlechrome:// for iOS Chrome, microsoft-edge:// for iOS Edge, firefox:// for iOS Firefox) but only possible to externally launch with http and/or https URL from other apps, let alone running arbitrary malicious command within it internally like this issue.

Comment 1

[James Lee]

Attachment: 1863832.html

Comment 2

[James Lee]

Attachment: 1863832.mp4

Comment 3

[James Lee]

We can duplicate this to bug 1863831 while tracking these two issues separately soon after I report them.

1. Opening firefox-focus URI internally (this is not allowed on Safari, Chrome, Firefox as I explained) allows to trigger exploits based on that URI like UXSSes, file:// URI based address bar spoofing etc.

2. URI Origin Spoof on any legitimate site which is iOS Firefox Focus version of bug 1795715

Comment 4

[James Lee]

That was not true, the fix for 1863831 in https://bugzilla.mozilla.org/show_bug.cgi?id=1860075#c12 proved that this is caused by different root cause and so not duplicate, we need to track this separately.

Comment 5

[James Lee]

https://pwning.click/RPReplay_Final1706293790.mp4

Comment 6

[mreagan]

Jira: https://mozilla-hub.atlassian.net/browse/FXIOS-9492

Comment 7

[Razvan Litianu]

hello, is this still an issue? I tries testing it in the latest focus build and it ends up doing a google search for javascript:document.write(document.domain).

Comment 8

[James Lee]

Attachment: RPReplay_Final1721647611.mp4

That's because I didn't update to the new PoC demo yet, sorry about that.

PoC demo: https://pwning.geniuscoolcat.com/1863832_updated.php

Expected result: URI command fails and "hacked" doesn't display on site info of Top Origin Site

Actual result: URI command runs on Top Origin Site

Fix: Block running firefox-focus:// internal URI command inside Firefox Focus through window.open()

Comment 9

[James Lee]

Attachment: RPReplay_Final1721661112.mp4

There is also a side impact of this issue where we're able to request to open vulnerable browsers, apps with its vulnerability exploit on any legitimate site like https://google.com to users.

This side impact is basically iOS Firefox Focus version of bug 1795715

We are able to launch any app but I used iOS Kakaotalk app with UXSS exploit as an example.

Since UXSS is not fixed yet and I didn't get confirmation reply from them about mentioning to other security team, I replaced it to https://evil.com as an exploit demo example site.

Make sure Kakaotalk app is installed to reproduce this side impact.

Alternatively, We could launch exploit iOS Opera UXSS with PoC demo 2 if you are not able to test it with Kakaotalk app. I also replaced it to https://evil.com as an exploit demo example site, as I didn't get confirmation to share UXSS exploit from Opera too.

PoC demo: https://pwning.geniuscoolcat.com/1863832_side_impact.php

PoC demo 2: https://pwning.geniuscoolcat.com/1863832_side_impact_2.php

Comment 10

[James Lee]

Attachment: RPReplay_Final1721661145.mp4

Comment 11

[James Lee]

Actually, being able to run firefox-focus:// URI internally is not the main root cause of the problem here.

Suggested fix: Do not allow to run command over any site with Timeout based setTimeout window.open() through firefox-focus:// URI.

Comment 12

[mreagan]

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

Comment 13

[James Lee]

Attachment: RPReplay_Final1722181648.mp4

There is also another side impact which is Address bar Spoofing: https://pwning.geniuscoolcat.com/1863832_side_impact2.php

Comment 14

[mreagan]

Note: a fix has been merged for this (PR linked above) however the related Jira ticket is still in QA Needed status, so it's not entirely clear whether we can close this? I'll reach out to QA to see if they can provide confirmation that this is fixed.

Comment 15

[Liz Henry (:lizzard)]

mreagan, did you hear anything from QA ? It would be nice to know if we can close this and the related issue. Thanks!

Comment 16

[mreagan]

Following up with QA again. Will update shortly.

Comment 17

[Andrei Bodea[:andrei]]

Hello, please note that after checking all the comments and videos from above and here are my results:

• case 1 [Comment 8] video - PoC demo: https://pwning.geniuscoolcat.com/1863832_updated.php < This one redirects me to the www.google.com but there is a blank/white screen

• case 2 [Comment 9] video - PoC demo: https://pwning.geniuscoolcat.com/1863832_side_impact.php < This one redirects me to the www.google.com, but it's also asking if I want to open Focus in another app, after tapping on the Open nothing happens and google.com is displayed without issues also the URL is correct, also note that when the open Focus in another app prompt is displayed, when tapping on the cancel, the redirect is still correctly done to the google.com and the URL is correct in that situation too.

• case 3 [Comment 9] video - PoC demo 2: https://pwning.geniuscoolcat.com/1863832_side_impact_2.php < This one redirects me to the www.google.com, but it's also asking if I want to open Focus in another app:

  • When tapping open > It redirects me to Opera with the evil.com website open (In this case please note that if I multi task to Focus, google.com is displayed without issues.
  • When tapping cancel > it redirects me to the google.com (no issues the URL is correct and the website is correctly displayed)

Please note that I also tried on the Firefox Desktop version 130 to see what happens I will give the cases from above as example:
Case 1 - The address wasn’t understood Firefox doesn’t know how to open this address, because one of the following protocols (kakaotalk) isn’t associated with any program or is not allowed in this context. error was returned <This was the URL> kakaotalk://inappbrowser?url=https://evil.com after tapping on the cat image.

Case 2 - I was redirected correctly to the www.google.com after tapping on the cat image.

Case 3 - I was redirected correctly to the www.google.com after tapping on the cat image.

As I did not fully understand from the comments, can you please confirm that this is the intended behavior? For Case 1 2 and 3?

Comment 18

[Daniel Veditz [:dveditz]]

I am thoroughly confused at what this bug is about. The summary says

Full UXSS via opening Firefox Focus internally with URI Origin spoof

That's like 3 different bugs rolled into one.

comment 3 ignores the UXSS part (which is covered in bug 1863831) and talks about the second two bits: opening things using firefox-focus: and putting prompts over another page after a navigation. We already have bugs about the last one.

But the testcases seem to be doing other things. the one in comment 8 is back to doing UXSS and claims it worked in July 2024, but as far as i can tell that testcase was already fixed in bug 1863831 back in Focus v122 or 123.

The various testcases that load things in other apps are not this bug. It sucks that there are vulnerabilities in other apps, but those are problems in those other apps. That's why we ask the user before launching something external. Our actual prompt is unfit for this purpose because there's no context to safely answer the prompt, but that's also a known problem described elsewhere. [in short, the prompt should say WHICH SITE is trying to load the external app to combat spoofing by overlay or by framed content (e.g. ads). The prompt should also say what app we're going to open, or at least the scheme we're looking for. If I'm browsing and a restaurant page wants to open the Yelp app that might be legit, but if I'm browsing in Firefox and the page tries to open something in a different browser entirely that's pretty darn suspicious.]

There are two confusingly named testcases:
https://pwning.geniuscoolcat.com/1863832_side_impact_2.php
https://pwning.geniuscoolcat.com/1863832_side_impact2.php

Comment 17 talks about the first one, but the MOVIE for the second one (comment 13) is doing a "file:" scheme spoof. That might be related to and fixed by the patch mentioned in this bug? The actual live testcase doesn't match the movie, though: it's back to using javascript: so we can't use that to confirm the fix.

But the core of this bug from comment 3 is "Focus allows web content to use firefox-focus: URLs and it shouldn't". I agree, and that's what makes this bug not a duplicate of bug 1863831. But that has not been fixed here. We do want to process those URLs when they come from outside the app, and maybe we need to use them internally, but they should not be allowed from web content.

In the testcases that use it the user gets a prompt to "open in app". Whatever code is doing that might be the right bottleneck to check "wait a minute, we do NOT want firefox-focus: URLS here; don't show the prompt and don't open it!"

testcase: this link shouldn't work in focus

Comment 19

[Daniel Veditz [:dveditz]]

I should add that I'm disturbed that the live testcases seem to change on us and don't always match the movies or description made when they were first linked. ALWAYS grab copies of the testcases and attach them to the bug if the reporter does not. We can't depend on remote server content to stay the same, or even to still exist. A whole mess of James's testcases in older bugs that used the https://pwning.click domain seem to be gone and lost.

Comment 20

[James Lee]

Yes, as I mentioned on [e-mail] several times, which is mainly in Tom's "Bug Bounty Invoice Sent to Finance" Email for bug 1863831 with partial reward, UXSS part of this report has already been fixed so different ways to trigger UXSS, which is this report and bug 1874371 before the fix, needed to be considered when bug 1863831 were rewarded and as I also already mentioned several times, I believe that it could've been full reward when we included this and bug 1874371 .

I recently checked once again that UXSS part for this report and bug 1874371 which are different ways to trigger deeplink based UXSS as I mentioned above, were fixed in bug 1863831 .

Please check the demo video I attached on comment 8 https://bugzilla.mozilla.org/attachment.cgi?id=9414095 to confirm comment 8 is actually not showing UXSS at all but it's about running file:// from framed sites to any Top Origin site with "file://hacked" as the demo video shows to prove we're loading file:// through window.open() with no prompt interaction.

I have to mention that I did stop uploading html attachment files anymore for a while after I moved from https://pwning.click (I'm not using this domain most of the time, for now) to https://pwning.geniuscoolcat.com where not functioning download feature was just fixed recently so I could now attach it with no hassle; which seems has caused this confusion in the meantime, but as I already mentioned, I talked about this UXSS part was already fixed several times through emails and please check explanation about comment 8 above. Also, as you mentioned before, Mozilla folks will always check the code change in the fix before assessing report, "the code speaks itself" in the fix from the updated PR mreagan added in this report: https://github.com/mozilla-mobile/firefox-ios/pull/21193 where the filter for "file:" is added to fix the "loading file:// with no prompt interaction" and "Address bar Spoofing impact comment 13" which will also fix triggering and address bar spoofing with file:// URI externally from Safari or other popular apps: https://bugzilla.mozilla.org/show_bug.cgi?id=1873248 so they all need to be considered as the impact of this report that was fixed by the fix in https://github.com/mozilla-mobile/firefox-ios/pull/21193

Thus, accurate description for this report would be following: "Running file:// via wondow.open() with no prompt, deeplink and Address bar Spoofing" instead of "opening Firefox Focus internally with URI Origin spoof"

Summary:

• What has been fixed in this report?

1. https://bugzilla.mozilla.org/attachment.cgi?id=9414095

Running file:// with no prompt interaction via window.open() in comment 8

2. https://bugzilla.mozilla.org/attachment.cgi?id=9416476

file: based Address bar Spoofing in comment 13

3. https://bugzilla.mozilla.org/attachment.cgi?id=9375613

bug 1873248 has also been fixed by this: Externally triggering file: to reproduce 1,2 impacts from Safari or other popular apps.

• What has not been fixed in this report?

URI Origin Spoof to launch vulnerable browsers from any legitimate site: Asking to open other apps on "https://google.com" for example, as you can check from the demo video https://bugzilla.mozilla.org/attachment.cgi?id=9414162 in comment 9 is iOS Firefox Focus version of this sec-moderate report: bug 1795715

I'll newly report this since it still works after the fix.

Additional note, in case emails I sent will stay unread: There are 2 "duplicate reports" by later reporters and they got rewarded where I was actually the first reporter of those reports but there is no update on report and advisory, until today. This need to be checked too.

Thanks!

Comment 21

[Daniel Veditz [:dveditz]]

URI Origin Spoof to launch vulnerable browsers from any legitimate site: Asking to open other apps on "https://google.com" for example, as you can check from the demo video https://bugzilla.mozilla.org/attachment.cgi?id=9414162 in comment 9 is iOS Firefox Focus version of this sec-moderate report: bug 1795715

That part is a duplicate of earlier bug 1328815 for Firefox on iOS and bug 1812522 for focus iOS (if not earlier ones, since obviously bug 1328815 was going to apply to focus as well)

Comment 22

[Daniel Veditz [:dveditz]]

Attachment: file spoof testcase

The testcase linked in comment 8 seems to be back to testing file: so I'm attaching it to the bug to preserve it.

Additional note, in case emails I sent will stay unread: There are 2 "duplicate reports" by later reporters and they got rewarded where I was actually the first reporter of those reports but there is no update on report and advisory, until today. This need to be checked too.

Your bug reports are complex and overlapping, which confuses developers and (as seen in comment 17) the QA folks trying to verify the fix. Developers may make incorrect assessments that the fix for another of your bugs will solve a particular one so they leave it alone. In the mean while another developer discovers a later-filed bug with a clear distinct issue and fixes it, not realizing that was part of one of the complex cases.

We need two separate bugs

1. focus content should not be allowed to open firefox-focus: URLs
2. file: URLs can be used for spoofing.

We have this bug (1863832) and bug 1873248. Bug 1873248 is essentially a duplicate of comment 8, but rather than duplicate it let's use it for the file: fix. It's a very nice, clear, single-issue bug that matches the patch in https://github.com/mozilla-mobile/firefox-ios/pull/21193/files

We can turn this bug into the "don't open firefox-focus: URLs" bug, which is not fixed. This bug is very messy so I'll abuse the "User Story" to try to move this essential to the top for better visibility.

Am I missing something? Is there a better suggestion?

Comment 23

[Daniel Veditz [:dveditz]]

This goes for Firefox for iOS's firefox://open-url? schemes as well, if we forgot to fix that as part of Muneaki's bug.

Matt: please make sure this is covered for Firefox for iOS, and make sure it's either "fixed", "we have a bug already", or file a new bug for it.

Comment 24

[mreagan]

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

This goes for Firefox for iOS's firefox://open-url? schemes as well, if we forgot to fix that as part of Muneaki's bug.

Matt: please make sure this is covered for Firefox for iOS, and make sure it's either "fixed", "we have a bug already", or file a new bug for it.

In testing Focus I could readily reproduce the problem, but in Firefox iOS it appears links with the associated scheme (e.g. firefox://open-url?url=…) do not work. So it doesn't appear that we require a separate ticket for Firefox.

Comment 25

[James Lee]

Hmm, I see.

file: based attacks are all resolved by that fix though, but if this report is not going to be closed and stay opened because of the behaviour of running firefox-focus:// URI internally, then I'll have to add the focus deeplink based attacks here soon.

Comment 26

[James Lee]

Attachment: 1863832_new.html

Please make sure the new second fix to block running firefox-focus:// in Focus app also resolves this issue- Address bar Spoofing based on firefox-focus:// deeplink: https://pwning.geniuscoolcat.com/1863832_side_impact3.php

Comment 27

[mreagan]

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

Comment 28

[mreagan]

Looks like there was an additional follow-up PR for this here: https://github.com/mozilla-mobile/firefox-ios/pull/21919

Comment 29

[James Lee]

Yes, this PR https://github.com/mozilla-mobile/firefox-ios/pull/21919 is the fix for a third issue I added in comment 26 for the case running through window.open() and it seems the fix is working.

Comment 30

[mreagan]

Note: I'm attempting to get confirmation on whether the fix has been fully validated and tested for v131, the related engineering ticket in Jira hasn't been updated unfortunately and so it's unclear what the status is. I'm reaching out again to confirm.

Comment 31

[mreagan]

Note: the related Jira was validated by QA, it appears the Bugzilla was just never closed; the Jira was marked Fx132.

Comment 33

[mreagan]

Attachment: advisory.txt

Comment 34

[James Lee]

Although I already explained in scattered comments and reports, since there were no follow up from the engineer to confirm I'll organise all together once more to wrap it up.

I do agree that Issues with multiple impacts from running file:/ URI inside the browser internally to conduct Spoofing attack via this, additional impacts which were fixed together but different way to trigger them via externally opening firefox-focus instead inside of the browser like this report with bug 1873248 and abusing "Open in Default Browser" bug 1874371 that were resolved by First and Second fix are overall high-end of sec-moderate (except the one separate UXSS impact of bug 1874371 with 1874371.html)

Third fix https://github.com/mozilla-mobile/firefox-ios/pull/21919 resolved two different way of Address bar Spoof which has a same impact to this bug 1816007 sec-high issue (Enough time for user to allow opening other app from browser to conduct Address bar Spoofing attack, which is explained why this type of attack grants sec-high in https://bugzilla.mozilla.org/show_bug.cgi?id=1816007#c8)

https://geniuscoolcat.com/Third_Fix_1.mp4

https://geniuscoolcat.com/Third_Fix_2.mp4

Comment 35

[mreagan]

(In reply to James Lee from comment #34)

Although I already explained in scattered comments and reports, since there were no follow up from the engineer to confirm I'll organise all together once more to wrap it up.

Thanks for adding the summary James. Let me know what you were attempting to confirm and I'll try to help if I can; it looks like this ticket may have had some overlap with others so I'm not clear on what information you were waiting for. Thank you.

Comment 36

[James Lee]

Thanks for your reply mreagan, I just meant there was no QA follow-up for this report to confirm these 3 different issues from some engineer(s) unlike most of my other fixed reports.

I wanted to emphasize that 3 different fix resolves 3 different issues with multiple impacts which has been explained but scattered on comments and other reports which might get missed during the assessment, please note that all these impacts need to be considered too.

Another important thing to be noted is that the second fix resolved multiple spoof attacks except window.open() Address bar Spoofing not link based Address bar Spoofing (Second fix resolved link based firefox-focus Address bar Spoofing with https://facebook.com:83 where PoC demo link: https://pwning.geniuscoolcat.com/1863832_fix2.php, PoC demo video: https://geniuscoolcat.com/Second_Fix_1.mp4 and tel://facebook.com PoC demo link: https://pwning.geniuscoolcat.com/1863832_fix2_2.php, PoC demo video: https://geniuscoolcat.com/Second_Fix_2.mp4) that required Third fix, where we could've also reproduced multiple issues including spoofing which was fixed in Third Fix and running file:/, spoofing attack via window.open() or from external app like Safari with bug 1873248 that was fixed in First fix, which would still work in latest version if there was no Second fix https://github.com/mozilla-mobile/firefox-ios/pull/21754 which is for blocking link (or linked image) based spoof but not via window.open() which was separately fixed in Third fix https://github.com/mozilla-mobile/firefox-ios/pull/21919 (Address bar Spoofing with https://facebook.com:83 where PoC demo link: https://pwning.geniuscoolcat.com/1863832_side_impact3.php, PoC demo video: https://geniuscoolcat.com/Third_Fix_1.mp4 and tel://facebook.com where PoC demo link: https://pwning.geniuscoolcat.com/1863832_side_impact4.php and PoC demo video: https://geniuscoolcat.com/Third_Fix_2.mp4 via firefox-focus URI through window.open() from comment 26 .

Comment 37

[Daniel Veditz [:dveditz]]

I can't even follow comment 36. Are those all filed as different bugs? If so (some are, clearly) we will deal with them in those bugs.

Comment 38

[Daniel Veditz [:dveditz]]

It looks like we considered that the high severity UXSS issue here was the same as bug 1863831, and then paid a bounty for it even though it turns out the UXSS part was actually fixed by bug 1860075 -- meaning that should have been a duplicate and not received a bounty.

The part that was NOT a duplicate (using the firefox-focus: url for various misdeeds) was left in this bug and then eventually fixed. The remaining issues were much less severe than the UXSS issue that we mistakenly considered a separate issue in bug 1863831 so we think the bounty for this issue has already been well covered.

Comment 39

[James Lee]

I can't even follow comment 36. Are those all filed as different bugs? If so (some are, clearly) we will deal with them in those bugs.

It looks like we considered that the high severity UXSS issue here was the same as bug 1863831, and then paid a bounty for it even though it turns out the UXSS part was actually fixed by bug 1860075 -- meaning that should have been a duplicate and not received a bounty.

The part that was NOT a duplicate (using the firefox-focus: url for various misdeeds) was left in this bug and then eventually fixed. The remaining issues were much less severe than the UXSS issue that we mistakenly considered a separate issue in bug 1863831 so we think the bounty for this issue has already been well covered.

First of all, there is some huge confusion here; bug 1863831 and bug 1860075 are different so they required different separate fix.

The fix for bug 1863831: https://github.com/mozilla-mobile/focus-ios/pull/3973

The fix for bug 1860075: https://github.com/mozilla-mobile/focus-ios/pull/3989

Second, different bug reports filed by me which I mentioned here were fixed in this report together; bug 1873248 has been completely fixed by the First fix https://github.com/mozilla-mobile/firefox-ios/pull/21193 and bug 1874371 has been completely fixed by the Third fix https://github.com/mozilla-mobile/firefox-ios/pull/21919

--

The Fix for bug 1863831: URI Fix Up for firefox-focus:// deeplink "open-url" javascript URI resulting to UXSS

firefox-focus://open-url?url=javascript:document.write(document.domain)

which is https://github.com/mozilla-mobile/focus-ios/pull/3973

nishant (who wrote the fix) tested the wrong PoC demo link which was for bug 1863831 assuming that was for bug 1860075 which ended up mistakenly fixing firefox-focus:// deeplink UXSS bug 1863831 first https://github.com/mozilla-mobile/focus-ios/pull/3973
in bug 1860075 due to nishant not checking and asking for feedback for some of my comments at that time, please read 15 ~ 17 comments in https://bugzilla.mozilla.org/show_bug.cgi?id=1860075#c15 (Btw, I'm blaming no one for that situation of course, it seems like I could've explained and emphasized in better way)

Original Server Side Redirection UXSS bug 1860075 was then fixed later in https://github.com/mozilla-mobile/focus-ios/pull/3989

The fix for bug 1860075: URI Fix Up for "Server Side Redirection" of javascript URI resulting to UXSS

<?php header("Location: javascript:document.write(document.domain)", true, 302); ?>

which is https://github.com/mozilla-mobile/focus-ios/pull/3989

As you can check from two fix, this is not true at all since bug 1863831 and bug 1860075 are two different issues required very different separate fix https://github.com/mozilla-mobile/focus-ios/pull/3973 and https://github.com/mozilla-mobile/focus-ios/pull/3989
where bug 1863831 is deeplink UXSS (https://github.com/mozilla-mobile/focus-ios/pull/3973) and bug 1860075 is UXSS via 30x redirect (https://github.com/mozilla-mobile/focus-ios/pull/3989).

Then there were 3 different issues which are at least high-end of sec-moderate each one due to "multiple" spoofing impacts for each fix leading to multiple spoofing attack (they're indeed less severe than UXSS but not much less, considering all impacts) were fixed here and all of them are completely separate issues which I requested to razvan to make sure they are all fixed one by one properly (hence, they are not "eventually" fixed at all).

Fix 1: https://github.com/mozilla-mobile/firefox-ios/pull/21193

Two different issues: this also fixed bug 1873248 which is loading internal file:/ externally from Safari or Default apps, fixed loading file:/ internally in Focus browser and fixed file:/ based spoofing in this report.

Fix 2: https://github.com/mozilla-mobile/firefox-ios/pull/21754

<a> with <img> link Click based timeout Address bar Spoofing with either invalid port or URI command parameter (https://pwning.geniuscoolcat.com/1863832_fix2.php: Demo video https://geniuscoolcat.com/Second_Fix_1.mp4 and https://pwning.geniuscoolcat.com/1863832_fix2_2.php: Demo video https://geniuscoolcat.com/Second_Fix_2.mp4), which is giving enough time for user to confirm leading to Full Address bar Spoofing which is the same impact of other reporter's fixed issue bug 1816007 / https://bugzilla.mozilla.org/show_bug.cgi?id=1816007#c5 (https://youtu.be/watch?v=NO8rr4R2gGM to confirm that Android Firefox Address bar Spoofing issue has the same impact to this iOS Firefox Focus Address bar Spoofing issue) this report is also letting user for confirmation by waiting enough time for opening URI from Android Firefox leading to Full Address bar Spoofing.

Fix 3: https://github.com/mozilla-mobile/firefox-ios/pull/21919

We were able to bypass the fix and reproduce multiple spoofing issues via launching it from webview instead, which could've been done via window.open() from a Cross-Origin frame to launch it from a webview, and thus bypassing the fix, including file:/ based attack (https://pwning.geniuscoolcat.com/1863832_side_impact.php: Demo video https://geniuscoolcat.com/RPReplay_Final1728516797.mp4) and timeout Address bar Spoofing via file:/ URI (https://pwning.geniuscoolcat.com/1863832_side_impact2.php: Demo video https://geniuscoolcat.com/RPReplay_Final1728516902.mp4)

The third fix for these window.open() timeout Address bar Spoofing was to block launching firefox-focus:// deeplink from webview entirely, so this fix ended up fixing all of these multiple issues at once.

I again requested to razvan to make sure this fix spoofing issue I showcased too and that ended up fixing multiple issues because it blocked opening firefox-focus:// from webview altogether; which means different ways to launch firefox-focus:// deeplink like "Open Link" or "Open in Default Browser" for example, won't be also able to run deeplink but this can only be launched from external apps now.

The showcased window.open() based timeout Address bar Spoofing is same impact to Click based spoofing since we're running firefox-focus:// URI internally triggered by click event from window.open() here instead of linked image with <a> anchor tag like the second issue, with either invalid port or URI command parameter (https://pwning.geniuscoolcat.com/1863832_side_impact3.php: Demo video https://geniuscoolcat.com/Third_Fix_1.mp4 and https://pwning.geniuscoolcat.com/1863832_side_impact4.php: Demo video https://geniuscoolcat.com/Third_Fix_2.mp4) which the fix blocked loading firefox-focus:// URI from a webview altogether as I mentioned: This also fixed bug 1874371 as a result, since UXSS part of this bug abuses loading of firefox-focus:// URI from a webview inside of Firefox Focus browser which is now entirely blocked so this UXSS issue were fixed too.

As I mentioned in one of the comments above, timeout Address bar Spoofing issue from webview could've also been reproduced without Click based or window.open() based spoofing attacks, but via abusing "Open Link" or "Open in Default Browser" in Focus instead (Running file:/ URI through firefox-focus:// URI with "Open in Default Browser": https://pwning.geniuscoolcat.com/1874371_side_impact.php / Demo video https://geniuscoolcat.com/RPReplay_Final1728514122.mp4 , Address bar Spoofing through file:/ and firefox-focus:// URI with "Open in Default Browser": https://pwning.geniuscoolcat.com/1874371_side_impact2.php / Demo video https://geniuscoolcat.com/RPReplay_Final1728515280.mp4 , Address bar Spoofing with either invalid port or URI command parameter: https://pwning.geniuscoolcat.com/1874371_side_impact3.php / Demo video https://geniuscoolcat.com/RPReplay_Final1728515467.mp4 and https://pwning.geniuscoolcat.com/1874371_side_impact4.php / Demo video https://geniuscoolcat.com/RPReplay_Final1728515566.mp4 ) which are additional impacts, while it's a bit less impactful than Click based timeout Address bar Spoofing and window.open() timeout Address bar Spoofing.

Comment 40

[James Lee]

I'm adding it once again since that was the attempt to add more needinfo which didn't work and cancelled the earlier one instead.

Thanks!

Comment 41

[James Lee]

Fixed in Focus 122: bug 1863831 == https://github.com/mozilla-mobile/focus-ios/pull/3973

Fixed in Focus 123: bug 1860075 == https://github.com/mozilla-mobile/focus-ios/pull/3989

Above is just simple two lines of ultimate proof that they are NOT a duplicate - thus these 3 spoofing issues and UXSS issue fixed in here should be considered for bounty reward.

Please verify and restore a sec-bounty? flag accordingly.

Comment 42

[James Lee]

Hi, please restore a sec-bounty? flag since comment 38 is incorrect and those two are not duplicate issues, which means these 3 spoofing issues and bug 1874371 UXSS issue should be assessed for a bounty reward, which is also what I asked to verify first before any step forward, in email.

Comment 43

[James Lee]

This is really unfair from Mozilla Security.

bug 1863831 was not rewarded as higher impact but with lesser impact in that category ($8000) compared to Full UXSS like bug 1860075 ($10000) and that lesser impact of UXSS was only considered and assessed for bug 1863831 reward, which means this bug 1863832 was completely missed, ignored and not awarded by Mozilla Security.

For the reference, I'll be politely asking Mozilla Security in the future, about using this case as one of the materials in training courses I'll be likely giving on Private and Public conferences from end of this year and/or early next year in worst case. The content I'll be using will be sent to Mozilla Security to ask their acceptance, appropriately.

While I appreciate correctly assessing most reports sent by reporters, Mozilla is not accepting the mistake in comment 38 lead to this situation but they kept their decision without admitting the contribution in comment 8 and comment 26 I made, which doesn't overlap with bug 1863831 which Simon of Mozilla Security claimed to be, was not true.

Duplicate UXSS issue report bug 1874371 was also missed and not considered for reward together in this bug 1863832 report of Address bar Spoofing issues.

Mozilla is keeping their decision from comment 38 even if it was a mistake to cancel the sec-bounty? flag, I proved bug 1863831 and bug 1860075 were not duplicate so this report should've been assessed for reward, together with detailed points of 3 spoofing issues I, reporter requested from comment 8 to be fixed, which is NOT an engineer's work, fixes would've never happened without my contribution.

Also, duplicate bug of this report that has been fixed in comment 28 by my request from comment 26 that was UXSS launched from Frame which is the reason comment 28 of blocking from webview frame and window entirely fixed that UXSS issue to in my bug 1874371, which has been fixed in this report like I mentioned, by my individual request in comment 26, was ignored and not considered for reward too.

We're all humans who make mistakes time to time, but Mozilla did not admit it which is the easy part and just let reporter's effort to be ignored.

Responsible people are lmarceau in https://bugzilla.mozilla.org/show_bug.cgi?id=1863831#c20 forgetting to add a correct fix commit of https://github.com/mozilla-mobile/focus-ios/pull/3973 into bug 1863831 lead to dveditz assuming bug 1863831 was duplicate to bug 1860075 and cancel a sec-bounty? flag for this report in comment 38 - dveditz concluded to cancel sec-bounty? flag for this report in comment 38 from this misunderstanding of double rewarding, which is proven to be not true.

Then Mozilla Security later changed their words after confirming it, that the reason for not awarding bug 1863832 was actually because it overlaps with bug 1863831 .

I again proved that's not truth too, all fixes were from my individual contribution that lead to 3 fixes in this report which could be confirmed in comment 8 and comment 26 in this report, this report should've been closed because the engineer who wrote the fix assumed there was no issue in this report!

comment 7

hello, is this still an issue? I tries testing it in the latest focus build and it ends up doing a google search for javascript:document.write(document.domain).

Flags: needinfo?([e-mail])

Engineer requested needinfo to my email address that there is no issue and it just ends up doing a google search for javascript:document.write(document.domain) which means UXSS part is fixed!

I, then started my contribution by discovering bugs starting with the first Address bar Spoofing bug from comment 8 and cancelled the needinfo in comment 9 with some additional details.

All these fixes were due to reporter, me taking actions of proving there are still valid Address bar Spoofing issues that needed to be fixed.

Despite all this, Mozilla Security decided to ignore all these contributions and falsely concluded as "this overlaps to bug 1863831".

--

If saving engineers resource is always much more important than comfirming mistake from Mozilla of missed issues *I requested to fix in comment 8 and comment 26, there is no reason for me to trust Mozilla Security bounty anymore and continue future contribution, which Mozilla probably won't care too much, but the question is am I or will I be the only one be in this unfair situation with this case.

I'll keep updating on already sent reports and discovered issues, but I'll have to seriously consider my future contributions and how much time am I willing to risk it for the unknown that could like maybe even getting rejecting for rewards with false conclusion on valid issues, since there is no due diligence done here in this report from Mozilla Security lead this, as I mentioned above.