1843467 - (CVE-2024-53975) Firefox iOS SSL Lock Spoof via https://google.com:83

Status: VERIFIED FIXED

(Firefox for iOS :: General, defect)

Description

[James Lee]

We are able to spoof SSL Lock on Firefox iOS using non-existent port from non-secure http sites.

Test on: http://pwning.click/ffsslgoogle.php

Comment 1

[Andrew McCreight [:mccr8]]

Is there anything fundamentally different between this bug and bug 1843468? At a glance, I don't understand why they are filed separately.

Also, if you could include a screenshot it would help the triage process. Thanks.

Comment 2

[Andrew McCreight [:mccr8]]

The source of the linked paged is: <script>location="https://www.google.com:83"</script>

Comment 4

[Daniel Veditz [:dveditz]]

Granted that you can make the page look like google or facebook and then do this hung navigation to spoof the location bar, is the spoof page usable during this hung navigation? If it's not interactive that's not all that useful as a spoof. If the user stays there the navigation should eventually timeout and give the user a message (at least in Gecko; I haven't confirmed webkit behaves the same).

Comment 5

[James Lee]

This is SSL Lock Spoof from non-secure http website and we can prevent the time out problem using setInterval() to reload the page continuously.

Comment 6

[lmarceau]

JIRA ticket to track progress on issue https://mozilla-hub.atlassian.net/browse/FXIOS-7328

Comment 7

[James Lee]

Overcome timeout issue with setInterval(): https://pwning.click/ffsslock.php

Comment 8

[James Lee]

paste this link instead: http://pwning.click/ffsslock.php

Comment 9

[James Lee]

Please test on: https://pwning.geniuscoolcat.com/sslspoof.php

Expected result: http://evil.com stay in SSL Lock disabled state as the site is on insecure http.

Actual result: SSL Lock is enabled via navigation to legitimate site with closed port.

Comment 10

[Razvan Litianu]

Attachment: RPReplay_Final1723466428.mp4

I'm trying to replicate the behaviour but I see the unsecure lock icon.

Comment 11

[James Lee]

Thanks for your reply and video!

Ah, so that's why it didn't work, this is an issue on iOS Firefox but not on Focus.

I also updated PoC demo for this too, with longer timer, I'll upload a demo video and explanation when I can get access to my device.

Thanks!

Comment 12

[Razvan Litianu]

Hey Daniel,
I’ve found a fix for the SSL spoofing issue, but I have a few questions to make sure we’re heading in the right direction before finalizing the design.
The issue was that we were setting the secure icon status too early, and I’ve noticed that other browsers (like Safari) defer showing the icon until they receive confirmation from the delegate that the website has fully loaded. Currently, we display it immediately, and I’m wondering if you see any potential issues with switching to a deferred approach.
Also, when do browsers typically confirm secure loading, and what’s the best way to handle showing that status?
Let me know your thoughts!

This is the PR with a video showing the fix.

Comment 13

[Daniel Veditz [:dveditz]]

waiting until "fully loaded" can have the opposite, but equally bad, problem. In that case we could be showing the old URL (e.g. search or social media site) on top of the content from a malicious site that sent enough initially that we start rendering the spoofing content, but then keep the browser waiting for more.

At some point we clear the old content and START rendering the new content. Ideally that is when we want to also change what URL we display.

This gets more complicated when the user has entered the new URL in the address bar. It would be weird and confusing if when the user hits <enter> or clicks the Go button we immediately restore the previous URL until we get enough content to render before switching back to what the user entered. If we don't do anything then the wrong URL appears over the old content (possibly for a long while given network tricks). If we try to combat that by immediately blanking the old content then users of slow networks can get unhappy staring t a blank screen for a long time.

That's one reason browsers have had "loading" indicators since the very earliest days, so users are warned they are in this transitional state.

I guess you're asking about the "secure" indicator specifically. We don't have to wait until the end, but we absolutely must wait until the old content is cleared and we've started rendering the new content. There are times you could get away with showing the future-url early over the old content (for example, the user types into the URL bar), but it definitely should NOT show a secure indicator.

I don't understand the movie in the PR referenced above. It shows you switching between different tabs that are already loaded -- don't we already know the correct state of those? What matters is what happens on navigation in the same tab

Comment 14

[Razvan Litianu]

Attachment: Simulator Screen Recording - iPhone 15 - 2024-09-19 at 17.53.07.mov

Hi,

Thanks for the reply,. I'm reuploading here a video how it behaves with the https://pwning.geniuscoolcat.com/sslspoof.php demo. In that PR I showcased how the secure icon behaves when loading secure/unsecured websites and how switching tabs updates the state. It is indeed not suggestive for this bug.
Let me know if you think it behaves correctly.

Comment 15

[James Lee]

Attachment: sslspoof.html

Hi Razvan, first of all, sorry for forgetting about this case with no update.

The demo video you attached there is the wrong one which seems it got mixed up when you tried to upload it.

That demo video of sslauths.php is bug 1843469 and I'm assuming that should be reproduced on iPad instead since I can't find the secure lock in there unlike when I reproduced that issue, by the way.

PoC demo for this bug 1843467 is https://pwning.geniuscoolcat.com/sslspoof.php but not https://pwning.geniuscoolcat.com/sslauths.php like you mentioned in your reply.

Thanks!

Comment 16

[James Lee]

It looks like this PR https://github.com/mozilla-mobile/firefox-ios/pull/21573 is a correct fix for this issue though, since we're not allowing to change the state before the site has been fully loaded.

Comment 17

[mreagan]

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

Granted that you can make the page look like google or facebook and then do this hung navigation to spoof the location bar, is the spoof page usable during this hung navigation? If it's not interactive that's not all that useful as a spoof. If the user stays there the navigation should eventually timeout and give the user a message (at least in Gecko; I haven't confirmed webkit behaves the same).

Is it possible to get a bit more clarification on this? In practice, while I can replicate the bug, it appears that most actions on the page during the reload loop ultimately force the SSL lock to be updated correctly. Additionally, the current POC eventually does timeout as Daniel mentioned.

My concern is that we might be making changes to sensitive code for the SSL/lock icon but that this specific POC is more of an academic/hypothetical, since it's hard to see how the page is in a usable state.

Let me know if I may be misunderstanding however. Thank you

(Note: PR 21573 appears to fix this issue; I've closed it temporarily but I have the same fix moved to a new local branch since Razvan is currently out and I'll be likely taking this ticket over for him.)

Comment 18

[mreagan]

Additional note: Safari on iOS has a slight problem with this POC also, in that during the refresh loop it does not show the 'Not Secure' text. Safari does not show the lock icon (AFAICS), however, as Firefox currently does, which is more misleading / problematic for Firefox.

Comment 19

[mreagan]

Note: PR https://github.com/mozilla-mobile/firefox-ios/pull/22474 (Since Razvan is out I've moved his work over to a new PR, there are a few small changes but largely the fix is the same).

Comment 20

[James Lee]

Let me know if I may be misunderstanding however. Thank you

Hi mreagan, thank you for the reply and I'm letting you know that's not true since this is a practical exploit that always work with active page with forms that's interactable with any HTML and CSS and there is a trick to delay the timeout to almost one minute like bug 1843468 which is more than long enough to exploit victims so this is almost same as a full spoof.

Please allow me to update this issue until next Monday.

Thanks!

Comment 21

[mreagan]

Thanks James for clarifying. I am investigating a few additional things, but have a PR up in the meantime so there should be a solution in place soon for this.

Comment 22

[James Lee]

Attachment: RPReplay_Final1728764616.mp4

Thanks for letting me know! I'll address some other points here, first of all.

Is it possible to get a bit more clarification on this? In practice, while I can replicate the bug, it appears that most actions on the page during the reload loop ultimately force the SSL lock to be updated correctly. Additionally, the current POC eventually does timeout as Daniel mentioned.

My concern is that we might be making changes to sensitive code for the SSL/lock icon but that this specific POC is more of an academic/hypothetical, since it's hard to see how the page is in a usable state.

I replied on the first part above already but to elaborate on both, we're able to delay the timeout to more than a minute with tricks like bug 1843468, which is almost same as a full spoof like bug 1263974 and bug 1557763 in terms of the long delay impact with interactable page during the navigation whether through location or copy / paste (like an attached demo video), as we could confirm by testing multiple cases.

I can see why one could confuse that the page seems not interactble though, that's because the test case with enabling http://evil.com which is the only loadable http site example I knew that doesn't have an interactable forms or so which requires other ways of testing to confirm it.

Comment 23

[Andrei Bodea[:andrei]]

Hello, please note that I used the following steps with Firefox v132 (46701) with iPhone 15 Pro (17.5):

• Visit https://pwning.geniuscoolcat.com/sslspoof.php
• Click the Click Here button
• Observe the resulting 'evil' page
• Expected: since the page is HTTP, you should NOT see a secure lock icon (HTTPS)
• Actual (bug): while the page is loading indefinitely, the lock icon (secure HTTP) shows

When I access the page for the first time it shows the HTTP lock Icon that the website is not secured, but after that, the page starts loading and the lock Icon shows that the page is secured (and after about a minute the page loads) and then it shows the HTTP icon (crossed lock icon).
Is this the intended behavior or it should show the lock icon (crossed) HTTP also when it loads the website?

Here is a video with the behavior.
Please let me know if this is the intended behavior and if we can close this issue or if it requires more work.

Comment 24

[mreagan]

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

Please let me know if this is the intended behavior and if we can close this issue or if it requires more work.

The video appears to show the old (incorrect) behavior, but I can't actually replicate that in testing locally. I checked to see if this fix was in the 132 branch and it appears it wasn't merged in time, so I believe we'll need to verify this fix with v133. I will update the Bugzilla fix version also.

(Note: it's possible we may end up backporting this fix to 132, that will probably require additional discussion, but for now I will update the ticket and move forward under the expectation that this will be fixed in 133 instead.)

Comment 25

[Andrei Bodea[:andrei]]

Verified as fixed on v133 (47401) with iPhone 15 Pro (18.2).
There is no secure lock displayed as the page is HTTP.

Comment 26

[mlichtenstein]

Attachment: advisory.txt