1868171 - Excessive Input Form with scroll down can spoof hidden address bar

Status: NEW

(Firefox for Android :: Toolbar, defect, P3)

Description

[Apip]

Attachment: Andorid_Firefox_POC.mp4

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36

Steps to reproduce:

The address bar can be used as a marker that we are in the domain we are aiming for, but currently, the Android Firefox browser application has a security bug that results in an excessive input form causing the display to scroll down to hide the address bar which causes the display to appear full screen without being there. toast notification. This can be exploited by attackers to spoof the UI.

1. Open https://omapip.my.id/input.html
2. Follow the instructions, scroll down and tap anywhere.
3. The address bar will be covered, like full screen mode

Actual results:

The address bar does not show the domain being accessed, as if it were in full screen mode

Expected results:

The address bar should remain in its position and not be crushed by anything when scrolling down, so that users are not confused about whether it is in full screen mode or not.

Comment 1

[Apip]

Attachment: input.html

Comment 2

[Apip]

Attachment: spoof.png

Comment 3

[Andrew McCreight [:mccr8]]

I can confirm that it isn't showing the address bar but I'm not sure what the behavior is supposed to be. Is the browser supposed to re-show the address bar when you interact with the page? Otherwise couldn't any page just fake a navigation somehow?

Comment 4

[Apip]

(In reply to Andrew McCreight [:mccr8] from comment #3)

I can confirm that it isn't showing the address bar but I'm not sure what the behavior is supposed to be. Is the browser supposed to re-show the address bar when you interact with the page? Otherwise couldn't any page just fake a navigation somehow?

The case I use is similar to the bug https://bugzilla.mozilla.org/show_bug.cgi?id=1344517 in 2017. However, it is different in behavior where I use excessive input size to create a display that can be scrolled down and overlap occurs. in the address bar.

If you ask Is the browser supposed to display the address bar again when you interact with the page? Of course it has to be displayed, because behavior that causes the address bar to suddenly disappear has the potential to be UI spoofing like a bug https://bugzilla.mozilla.org/show_bug.cgi?id=1344517 (CVE-2017-5395)

Comment 5

[Daniel Veditz [:dveditz]]

When I try the PoC the URL bar comes back when I scroll again. On other sites when the addressbar is gone, it doesn't come back just because I tap the page, it only comes back when you scroll. For example, if you're on a social media site you can "like" a post without causing the addressbar to show up.

It's definitely a spoof: maybe users will be fooled by the fake addressbars, but that is always a risk when we hide those on a potentially malicious site. The "tool" we've provided to detect that kind of spoof is wiggling your finger (scrolling the page) and this example doesn't suppress that.

Comment 6

[Apip]

any update on this?

Comment 7

[Daniel Veditz [:dveditz]]

Sorry for the burst of bugspam: filter on tinkling-glitter-filtrate
Adding reporter-external keyword to security bugs found by non-employees for accounting reasons

Comment 8

[Zac McKenney [:zmckenney]]

Reviewing this ticket, it appears this is not something we feel is a security concern and does not need fixed because we are hiding the toolbar as intended. This would also occur in other browsers that hide the toolbar, I don't think we need to change anything. Daniel, would you agree with this assessment and be OK with me closing the ticket as WONTFIX?

Comment 9

[Daniel Veditz [:dveditz]]

Attachment: self-contained testcase to load from bmo

Comment 10

[Daniel Veditz [:dveditz]]

we are hiding the toolbar as intended. This would also occur in other browsers that hide the toolbar, I don't think we need to change anything.

There are two important mitigations to this. First and by far most important: the addressbar MUST NOT autohide unless the user themselves has physically caused the scroll. If Content can make the toolbar go away by scrolling itself then it would be trivial to fake a navigation to another site. This has always been our rule, I just wanted to make that explicit—especially since it's not clear from the current bug summary that it's the user doing the scrolling and not the "excessive form". Second mitigation: users can turn off the auto-hiding address if they want to protect themselves from this kind of thing, although we can't count on this because 1) people rarely change the default, and 2) the two-row "fat" toolbar in Fenix Nightly makes that option particularly unattractive once that new UI makes it to release.

Daniel, would you agree with this assessment and be OK with me closing the ticket as WONTFIX?

That seems fair. The only possible "fix" is disabling the autohiding toolbar, which user and competitor research says we need to have.