Closed Bug 1860075 (CVE-2024-26284) Opened 2 years ago Closed 2 years ago

iOS Firefox Focus 302 redirect UXSS

Categories

(Focus :: Security: iOS, defect)

Product:
Focus
Component:
Security: iOS
Version:
Firefox 123
Type:
defect

Tracking

(fxios123)

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
fxios 123 ---

People

(Reporter: proof131072, Assigned: lmarceau, NeedInfo)

References

Details

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

Attachments

(3 files)

1860075.mp4
3.92 MB, video/mp4
Details
GitHub Pull Request
53 bytes, text/x-github-pull-request
Details | Review
advisory.txt
212 bytes, text/plain
Details

We are able to perform UXSS using 302 redirect where iOS Firefox Focus allows to perform UXSS on any site you're visiting. We can reproduce this with Google search by visiting one of the malicious sites with PoC from the search results and that's just one of the examples how this could be used to exploit mass users.

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

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

Flags: sec-bounty?
Group: firefox-core-security → mobile-core-security
Component: Security → Security: iOS
Product: Firefox → Focus
Attached video 1860075.mp4 —

This violates the standards even: there are a limited number of schemes browsers are supposed to accept as the destination of a 3XX Location header. Javascript: is definitely right out, but the spec has switched to a more conservative "allow-list" approach.

Keywords: csectype-sop, sec-high

We should confirm this does not work on Firefox for iOS just in case, but I'm sure James would have reported it if that was broken also

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

For more information, please visit BugBot documentation.

Flags: needinfo?(jeevans)

I was wondering same thing and I found this report recently which is the reason why it doesn't work on iOS Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1588928

It should be sec-critical even without this since identical impact report https://bugzilla.mozilla.org/show_bug.cgi?id=1588928 was assigned as sec-critical but we are also able to do silent background navigation opening https://pwning.click/googleloc.php and leave browser to open Focus from other browsers/apps like iOS Chrome with <a href="firefox-focus://open-url?url=https://pwning.click/Focus302UXSS.php">Open with Firefox Focus</a> to achieve Full UXSS which is solid sec-critical.

Hi, what am I looking at here?

Again could you give proper steps considering when I go https://pwning.click/Focus302UXSS.php nothing is happening.

Please go to https://google.com and open https://pwning.click/Focus302UXSS.php or open https://pwning.click/googleloc.php and leave the browser to open Firefox Focus from other browsers or apps with https://pwning.click/focuslink.php

** leave the browser to open Firefox Focus from other browsers or apps with https://pwning.click/focuslink.php

James, what does this mean? You mean set a deeplink or is all of this happening from the same tab inside focus. Sorry but want to make sure I have the correct steps so we can implement a proper fix.

Thanks

Flags: needinfo?(proof131072)

Please open https://google.com and go to https://pwning.click/Focus302UXSS.php

Flags: needinfo?(proof131072)
Attached file GitHub Pull Request —
Assignee: nobody → lmarceau
Version: unspecified → Firefox 122
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED

Hello, please note that Nish told me to test it with the following steps:

  • Open Focus and go to google.com
  • Background Focus
  • Open Safari and then go to https://pwning.click/focuslink.php
  • There will be a link in that safari page that when tapped opens Focus
  • We make sure that no js is run on the page via deeplink
    I was not able to verify it with that link and here is what happens.

Based on the last comment I tried to open it like you mentioned James above: Please open https://google.com and go to https://pwning.click/Focus302UXSS.php
But no browser can open https://pwning.click/Focus302UXSS.php - so even if I open google.com on Focus and then access that link to another browser to try and redirect to Focus, I can't do that, should I write that URL after I access google.com?

When I opened https://pwning.click/Focus302UXSS.php over google.com the www.google.com text was displayed on a blank page and the URL was: pwning. click but the loading bar was stuck at the beginning (under URL bar). Like you see in the video above.
When I tap on the URL it shows what I pasted aka this one https://pwning.click/Focus302UXSS.php.

Looking forward for a way to verify this issue.

That's wrong step and I never provided that :\ that's basically https://bugzilla.mozilla.org/show_bug.cgi?id=1863831 not this UXSS.

I clearly mentioned on https://bugzilla.mozilla.org/show_bug.cgi?id=1860075#c8 it's https://pwning.click/focus302link.php not https://pwning.click/focuslink.php for other case, why did feedback stopped and fix for https://bugzilla.mozilla.org/show_bug.cgi?id=1863831 happened without notifying instead?

I have different bugs that were fixed by this patch which shouldn't happen if it was correct fix for this bug.

On this issue, you just verified it.

"When I opened https://pwning.click/Focus302UXSS.php over google.com the www.google.com text was displayed on a blank page and the URL was: pwning. click but the loading bar was stuck at the beginning (under URL bar). Like you see in the video above.
When I tap on the URL it shows what I pasted aka this one https://pwning.click/Focus302UXSS.php."

What you reproduced is javascript:document.write(document.domain) is running on https://google.com as I mentioned.

Please notify me first and test with the steps I provided instead of other steps I might've provided on different report. Thanks.

So we need to re-open this bug and close https://bugzilla.mozilla.org/show_bug.cgi?id=1863831

Group: mobile-core-security → core-security-release

Nish and/or Laurie, can you take a look at the last few comments?

Flags: needinfo?(nish.bhasin)
Flags: needinfo?(lmarceau)
Flags: needinfo?(jeevans)

Thank you for highlighting these security issues. We acknowledge the complexity and importance of the bugs you've reported. To ensure our QA team can effectively test and address these concerns, we require more specific and detailed testing steps. We encountered difficulties with the current instructions, particularly with the link https://pwning.click/Focus302UXSS.php and your earlier steps.

Could you please provide a revised, clear set of steps for each bug, starting with this particular issue? Detailed instructions are essential for us to accurately replicate and resolve the problems.

Flags: needinfo?(nish.bhasin) → needinfo?(proof131072)

Thanks for the reply, this was already reproduced by Andrei https://bugzilla.mozilla.org/show_bug.cgi?id=1860075#c14 unintentionally and only step here is https://bugzilla.mozilla.org/show_bug.cgi?id=1860075#c11

To check this vulnerability, we must understand that we are checking document.write is executing with the context of https://google.com which will return www.google.com on blank page. I believe there was confusion on that part where checking JS URL running on address bar instead, which is not the correct way to verify in this case.

Thus, address bar is nothing to do here and it'll point to https://pwning.click/Focus302UXSS.php while 302 redirected JavaScript is running on https://google.com context.

https://pwning.click/focuslink.php is suppose to be a wrong link I pasted so I clarified that it should be https://pwning.click/focus302link but we were not able to communicate since then. So I can understand your perspective but I think it's better to talk each other if there was a problem on reproducing and ask to confirm if the wrong link https://pwning.click/focuslink.php is not the case and what should one follow before skipping that and proceeding the fix, which could be the wrong case like this one.

Flags: needinfo?(proof131072)

Hi, please provide steps for this bug in the following format

## Steps to reproduce
1. Launch Focus.
2. etc.
### Expected behavior
Add your explanation on what the expected behaviour is
### Actual behavior
Add your explanation for actual behaviour which is how the attack looks like
### Device & build information
Simulator (if you are using sim)
### Notes
Any notes

This is a sample bug: https://github.com/mozilla-mobile/focus-ios/issues/3684 that our QA best follows

What you are explaining is fine but I want you to provide very clear steps in the next comment for our QA. I rather not have our QA dig into the thread chain to find correct steps. Hope you understand

Flags: needinfo?(lmarceau) → needinfo?(proof131072)

There is multiple ways to reproduce this but since I mentioned several times on https://bugzilla.mozilla.org/show_bug.cgi?id=1860075#c11

  1. Open https://google.com on Focus

  2. Open https://pwning.click/Focus302UXSS.php

Expected behaviour: JavaScript doesn't run, we're staying on https://google.com

Actual behavior: blank page with www.google.com indicating that 302 redirected JavaScript on https://pwning.click/Focus302UXSS.php javascript:document.write(document.domain) was executed on https://google.com .

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

Flags: needinfo?(proof131072)

The link https://pwning.click/Focus302UXSS.php doesn't appear to be working. Tried on multiple devices and it's not navigable.

That's weird, it works for me. Did you open https://google.com and then navigate to https://pwning.click/Focus302UXSS.php ?

It won't do anything and only display https://pwning.click/Focus302UXSS.php on address bar with javascript:document.write(document.domain) on target site.

When I opened https://pwning.click/Focus302UXSS.php over google.com the www.google.com text was displayed on a blank page and the URL was: pwning. click but the loading bar was stuck at the beginning (under URL bar). Like you see in the video above.
When I tap on the URL it shows what I pasted aka this one https://pwning.click/Focus302UXSS.php.

Looking forward for a way to verify this issue.

Please follow like Andrei to reproduce this.

(In reply to James Lee from comment #24)

That's weird, it works for me. Did you open https://google.com and then navigate to https://pwning.click/Focus302UXSS.php ?

What version of iOS, Safari, and Firefox Focus, are you testing with?

(Unfortunately I don't have an idevice so I can't test. Gecko refuses to handle the javascript URI in the location header at all - perhaps iOS webkit has started doing the same?)

Flags: needinfo?(proof131072)

(In reply to James Lee from comment #25)

Please follow like Andrei to reproduce this.

This is what we mean by having clear STR (steps to reproduce) - if I follow the steps, I should be getting the issue which isn't the case right now as I would need to piece out what "do as Andrei" means. If the STR are not complete, then it leaves the door open for interpretation/miscommunication, and the bug not being fixed. Also as Nish and Gijs pointed out, it would also be very helpful to know which device and version you are testing on. Please ensure the STR are clear on all of your bug tickets. We love your contributions, but having complete STR and information on the bug at hand would make this much easier. Thank you.

Hello, I've checked the comments from above a few times and I believe this will help to have something that puts everyone on the same page:

I tried to reproduce this issue on the latest Focus for iOS v122 (17561) with iPhone 15 Pro (17.1.2).

Steps to reproduce

  1. Open https://google.com on Focus.
  2. As Focus has only one tab, tap on the URL and write https://pwning.click/Focus302UXSS.php
  3. Press enter in order to access https://pwning.click/Focus302UXSS.php

Expected Behavior

JavaScript doesn't run, we're staying on https://google.com

Actual behavior

There is a blank page with www.google.com text, the URL is displayed as pwning.click and the loading page bar is stuck at 10%.

Notes

Please note that with a refresh of the page (swipe down) the google.com is correctly displayed again.
Please note that there is no "indicating that 302 redirected JavaScript on https://pwning.click/Focus302UXSS.php javascript:document.write(document.domain) was executed on https://google.com ." as James Lee mentioned here.
(In reply to James Lee from comment #22)

Actual behavior: blank page with www.google.com indicating that 302 redirected JavaScript on https://pwning.click/Focus302UXSS.php javascript:document.write(document.domain) was executed on https://google.com .

I prepared more videos:

  • Google Chrome - This site can't be reached error was displayed and on the URL was the following javascript:document.write(document.domain)
  • Firefox Focus v122 (17561) - There is a blank page with www.google.com text, the URL is displayed as pwning.click and the loading page bar is stuck at 10%.
  • Firefox for iOS v122 (37686) - The https://pwning.click/Focus302UXSS.php is instantly transformed into www.google.com and the loading bar is stuck at 10%, when clicking on the URL bar nothing happens as the google.com is correctly displayed.
  • Brave latest version - nothing happens the google.com is still displayed correctly.
  • Safari latest version - This site can't be reached error was displayed and on the URL was the following javascript:document.write(document.domain)

So based on the above information and what James commented above comments: Right now we are not returning javascript:document.write(document.domain) running on https://google.com but the URL pwning.click is displayed meaning that this issue is fixed.
But it's still weird (if you check the Focus video) how it's displayed.

Looking forward for some more information in order to verify this issue right.

No Safari, never said that, Focus browser on latest iOS is only prep and you guys are correctly reproducing but keep saying it's not working so I'm explaining same thing over and over. We need someone who can understand that www.google.com on blank page IS this UXSS vulnerabillity exploit working.

(In reply to Andrei Bodea[:andrei] from comment #28)

Please note that there is no "indicating that 302 redirected JavaScript on https://pwning.click/Focus302UXSS.php javascript:document.write(document.domain) was executed on https://google.com ." as James Lee mentioned here.
(In reply to James Lee from comment #22)

Actual behavior: blank page with www.google.com indicating that 302 redirected JavaScript on https://pwning.click/Focus302UXSS.php javascript:document.write(document.domain) was executed on https://google.com .

You are keep verifying that this vulnerabillity is not fixed, again. I already explained URL will display pwning.click and that's nothing to do with UXSS behaviour. Can someone come in here and verify that returning document.domain of www.google.com means you're UXSSing Focus and reproducing this report?

Flags: needinfo?(proof131072)

(In reply to lmarceau from comment #27)

(In reply to James Lee from comment #25)

Please follow like Andrei to reproduce this.

This is what we mean by having clear STR (steps to reproduce) - if I follow the steps, I should be getting the issue which isn't the case right now as I would need to piece out what "do as Andrei" means. If the STR are not complete, then it leaves the door open for interpretation/miscommunication, and the bug not being fixed. Also as Nish and Gijs pointed out, it would also be very helpful to know which device and version you are testing on. Please ensure the STR are clear on all of your bug tickets. We love your contributions, but having complete STR and information on the bug at hand would make this much easier. Thank you.

Did this way before I was asked, clear STR was always there, it's just that this issue has been misunderstood; URL is https://pwning.click/Focus302UXSS.php while blank page shows www.google.com . That IS this UXSS report. Hopefully I don't need to comment anymore here by someone finally confirm this with no problem.

I have added another patch for this in this Focus PR
Once this gets merged and you have a build lets test against your steps. Instead of loading google or any site it should just stop after you visit https://pwning.click/Focus302UXSS.php (please only test on real device)

Flags: needinfo?(abodea)

Thanks! I hope we can communicate better next time. I was going to decide to add other cases since no one seems to got around, with clicking on site info telling you javascript: URI is running on https://google.com but since this is understood and under the fix, I might add it sometime later for future reference and why this grants higher severity.

Title is iOS Firefox Focus 302 redirect UXSS and it's 0% related to deep link, it was that me pasting wrong link just once caused all this, my bad. (I couldn't delete it like chromium bugs since bugzilla doesn't support delete)

https://bugzilla.mozilla.org/show_bug.cgi?id=1863831

Already reproduced in here due to misunderstanding. (Let me know if you want to reproduce iOS Mail App version though)

https://bugzilla.mozilla.org/show_bug.cgi?id=1863832

We just need to tap on cat to reproduce this.

Verified as fixed on v9000 (17565) with iPhone 15 Pro Max (17.1.2).
Here you can see the video made on the recent build and it can be seen that the JavaScript is not running and we remain on www.google.com.

Hello, Nish and Laurie waiting for your confirmation, as I cannot check yet the bugs posted by James above in his last comment, but if we track those in there, then we can consider this issue done.

Flags: needinfo?(nish.bhasin)
Flags: needinfo?(lmarceau)
Flags: needinfo?(abodea)
Flags: needinfo?(lmarceau)
Version: Firefox 122 → Firefox 123

Could we add Andrei to bug 1863831 and bug 1863832 reports?

Are we fixing them in 122 as well with https://github.com/mozilla-mobile/focus-ios/pull/3973 ? they need to be checked before if that's the case.

Hello, @James soon I will have access to those, and based on the priorities I will take a look there.

Thanks! please test with the version before 122 to reproduce them since we already checked the fix.

Is this fix https://github.com/mozilla-mobile/focus-ios/pull/3973 already done for 122? then we need check actual reports which are related to the fix: bug 1863831 and 1863832. We can't just patch it without checking them since the fix was done because of misunderstanding here, let's not forget that.

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

needinfo is not working here for some reason. Please let me know when you see this Nish.

This one and bug 1863831, bug 1863832 could be chained (bug 1863831, bug 1863832 could be chained with this one too) to increase the impact.

For posterity curl -i https://pwning.click/Focus302UXSS.php gives

HTTP/1.1 302 Found
Date: Tue, 23 Jan 2024 19:36:42 GMT
Content-Type: text/html; charset=iso-8859-1
Content-Length: 226
Connection: keep-alive
Server: Apache/2
X-Powered-By: PHP/5.5.22
Location: javascript:document.write(document.domain)
Age: 0

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>302 Found</title>
</head><body>
<h1>Found</h1>
<p>The document has moved <a href="javascript:document.write(document.domain)">here</a>.</p>
</body></html>
Flags: sec-bounty? → sec-bounty+
Alias: CVE-2024-26284
Attached file advisory.txt —
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: