1875824 - HTML Select Picker Can Show Over Any Site or Application

Status: RESOLVED DUPLICATE of bug 1875354

(Core :: DOM: Core & HTML, defect)

Description

[Shaheen Fazim]

Attachment: poc.html

HTML Select picker using showPicker() can open over any website or application on the user's computer, appearing all over the desktop as the user tries to navigate. Below is a proof-of-concept demonstration of a malicious site using showpicker, which opens with every interaction on the user's computer.

Steps to Reproduce:

1. Download the poc.html file.
2. Open the poc.html file in firefox for testing.

Tested on latest Nightly build version: 123.0a1, OS: Windows 11

Comment 1

[Shaheen Fazim]

Attachment: demo.mp4

Comment 2

[Oliver Medhurst [:canadahonk]]

Seems like we should close the picker if tab goes in the background? Should be relatively straightforward.

Comment 3

[Andrew McCreight [:mccr8]]

It looks like this was added recently in bug 1854112.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

:evilpie, since you are the author of the regressor, bug 1854112, could you take a look?

For more information, please visit BugBot documentation.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1854112

Comment 6

[:Gijs (he/him)]

It would be nice if we could do something more thorough than just restricting showPicker, given all the bugs I just added to "see also".

Comment 7

[Shaheen Fazim]

Friendly ping.

The issue might not seem significant from my original description, but this approach can be used for different kinds of attacks. It's like unlocking an ad pop-up that can't be stopped, on users' computers through the Mozilla browser, and it can also be overlaid over any other trusted sites for malicious purposes. I think it could be considered as UXSS without code execution, but it has the potential to pop up on any site with custom text.

Comment 9

[Shaheen Fazim]

Hi, currently, the Chromium team is working on a fix at https://chromium-review.googlesource.com/c/chromium/src/+/5237056.

Comment 10

[Shaheen Fazim]

(In reply to Shaheen Fazim from comment #9)

Hi, currently, the Chromium team is working on a fix at https://chromium-review.googlesource.com/c/chromium/src/+/5237056.

This patch adds visibility checks in content to prevent invisible or background tabs from creating <select> popups.

Can we implement a similar fix?

Comment 11

[Oliver Medhurst [:canadahonk]]

Bug 1877969 might fix this, needs further investigation. The change noted above could also be done for more robustness.

Comment 12

[Shaheen Fazim]

I believe this issue is more similar to Bug 877879 of a sec-high than sec-moderate. I would like the team to consider two points in this rationale:

1. Instead of an alert message with an origin, we are using a custom popup without any origin indicator, which can be placed on any part of the website, which is a better spoof than alert popups. It can also cover the whole browser's content if needed to make a fully spoofed website, which I have attached as an image demo.
2. Another point I would like to bring up is that, unlike all the different popups, this particular select option as a popup can be shown outside the browser renderer, not just in front of other user applications as well.

I strongly believe this is a sec-high issue deserving of a higher security rating. Daniel, I would appreciate your opinion on this.

Comment 13

[Shaheen Fazim]

Attachment: browser.png

Comment 14

[Shaheen Fazim]

Attachment: external.png

Comment 15

[Daniel Veditz [:dveditz]]

(In reply to Shaheen Fazim from comment #12)

I believe this issue is more similar to Bug 877879 of a sec-high than sec-moderate.

I'm not authorized to see bug 877879. Can you CC me on it?

I strongly believe this is a sec-high issue deserving of a higher security rating. Daniel, I would appreciate your opinion on this.

This is a horrible misfeature as implemented and can be used to annoy, harass, and scam victims. It does not give you any functional control over Firefox itself or the data/content from any other origin. It does not meet the criteria for high.

The chrome folks say their https://crbug.com/41494315 is "medium" also ("S2" in their tracker). That's the bug associated with the patch mentioned in comment 9

Comment 16

[Shaheen Fazim]

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

The chrome folks say their https://crbug.com/41494315 is "medium" also ("S2" in their tracker). That's the bug associated with the patch mentioned in comment 9

In Chrome, the issue does not affect as much as in Firefox. In Chrome, I was not able to open new windows, or the custom select option pop-up is not rendered over other applications as well. However, the issue is recognized as a site isolation issue and has been awarded a 3k. This exploit is particularly more severe for Firefox.

Comment 17

[Shaheen Fazim]

Attachment: chrome-fixed-demo.mp4

Comment 18

[Shaheen Fazim]

In Chrome, I was not able to open new windows

meaning the attacker could only render the popup on previously opened tabs (see attached video chrome-fixed-demo.mp4), not on a new desired tab. However, in Firefox, it's possible to cover any arbitrary URL by opening them and spoof it with custom select option content.

Comment 19

[Shaheen Fazim]

Friendly ping.

Comment 20

[Andrew McCreight [:mccr8]]

I believe that this depends on some spec work which is ongoing.

Comment 21

[Shaheen Fazim]

Hi, any update on this issue? Thanks.

Comment 22

[Oliver Medhurst [:canadahonk]]

Fixed with Bug 1877969 (afaik)

Comment 23

[Shaheen Fazim]

Attachment: retest.mp4

Retested on 129.0a1 (2024-06-21) (64-bit). The issue is still present. Has the fix not landed, or should we implement an additional fix for this as well?

Comment 24

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Shaheen Fazim from comment #23)

Created attachment 9410563 [details]
retest.mp4

Retested on 129.0a1 (2024-06-21) (64-bit). The issue is still present. Has the fix not landed, or should we implement an additional fix for this as well?

According to comment 22, this bug was fixed by bug 1877969, which landed on 2024-06-25. Would you mind updating your Nightly and testing again? Thank you.

Comment 25

[Tom Schuster (MoCo)]

I think this basically a duplicate of bug 1875354, so not yet fixed.

Edit: bug 1875354 makes it so it can be closed with [ESC], but it doesn't help with it overlapping other windows. I would assume we already have bugs for that?

Comment 26

[Shaheen Fazim]

Attachment: latest-retest.mp4

(In reply to Tom Schuster (MoCo) from comment #25)

I think this basically a duplicate of bug 1875354, so not yet fixed.

The common issue of opening the select option indefinitely aside, both issues I presented are different. One is hiding the fullscreen notification, and this one can be opened on a different site, tab, or application.

(In reply to Hsin-Yi Tsai (she/her) (REO Fx 129) [:hsinyi] from comment #24)

According to comment 22, this bug was fixed by bug 1877969, which landed on 2024-06-25. Would you mind updating your Nightly and testing again? Thank you.

Yes, I just got the update (69.6MB). Nice, it seems the new tab issue is resolved with this update by not consuming the activation. However, the select option is still opened with other applications, etc. We should close the select option when the opened site is not in focus.

Comment 27

[Shaheen Fazim]

Tested on: 129.0a1 (2024-07-01) (64-bit)

Comment 28

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Shaheen Fazim from comment #26)

Created attachment 9410606 [details]
latest-retest.mp4

(In reply to Tom Schuster (MoCo) from comment #25)

I think this basically a duplicate of bug 1875354, so not yet fixed.

The common issue of opening the select option indefinitely aside, both issues I presented are different. One is hiding the fullscreen notification, and this one can be opened on a different site, tab, or application.

(In reply to Hsin-Yi Tsai (she/her) (REO Fx 129) [:hsinyi] from comment #24)

According to comment 22, this bug was fixed by bug 1877969, which landed on 2024-06-25. Would you mind updating your Nightly and testing again? Thank you.

Yes, I just got the update (69.6MB). Nice, it seems the new tab issue is resolved with this update by not consuming the activation. However, the select option is still opened with other applications, etc. We should close the select option when the opened site is not in focus.

The problem with other applications seemed to be fixed by bug 1875354. The select option is closed properly, when using Firefox 130.0a1 (2024-07-15).

Comment 29

[Shaheen Fazim]

Attachment: test-after-fix.mp4

(In reply to Hsin-Yi Tsai (she/her) (REO Fx 129) [:hsinyi] from comment #28)

The problem with other applications seemed to be fixed by bug 1875354. The select option is closed properly, when using Firefox 130.0a1 (2024-07-15).

Just tested with the latest Firefox Nightly version 130.0a1 (2024-07-15). I can confirm this issue is fixed.

Comment 30

[Shaheen Fazim]

Attachment: test-after-fix.mp4

Comment 31

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Thank you very much for the verification.

Comment 32

[Daniel Veditz [:dveditz]]

This is the same underlying cause and fix as bug 1875354. There's one minor spoofing edge case that we're going to spin off as a new bug because this one is getting long and that would be confusing. [see bug 1909529]

Comment 33

[Daniel Veditz [:dveditz]]

Shaheen also reported bug 1909535, a different variant that wasn't fixed

Comment 34

[Shaheen Fazim]

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

This is the same underlying cause and fix as bug 1875354. There's one minor spoofing edge case that we're going to spin off as a new bug because this one is getting long and that would be confusing. [see bug 1909529]

I was under the impression that this fix, which consumes user activation, causes the popup blocker to require the user to explicitly allow this permission.

I also showcase this behavior in the first part of the video: latest-retest.mp4

Comment 35

[Shaheen Fazim]

Hi Daniel,

I think this issue is a bit misunderstood here.

I reported an issue which could show a malicious select option prompt on different website and applications. Looking at how this is fixed, we saw two fixes: see comment 22 and comment 28.

So both issues are fixed in two different bugs. I can agree that opening the selection option on different applications is fixed by Bug 1875354, which we could consider a duplicate. But the first part (where a malicious select option prompt opened on top of a different website) of my issue was considered fixed (which I later metioned it was not completyl fixed see my comment 23), and therefore first part was addressed by Bug 1877969 (opened 2024-02-01), following the reporting of this issue (2024-01-22).

So, I request that we reevaluate the possibility of a sec-bounty for this issue, if my comment is deemed valid.

Comment 36

[Daniel Veditz [:dveditz]]

(In reply to Shaheen Fazim from comment #35)

I reported an issue which could show a malicious select option prompt on different website and applications. Looking at how this is fixed, we saw two fixes: see comment 22 and comment 28.

Both those fixes were required to fix bug 1875354, for which you got a bounty.

In comment 29 you confirmed this bug was fixed. That turned out to be incorrect, but the fact that it was possible to make that mistake (and not just you) shows that the bulk of the issue in this bug is the same flaw as bug 1875354.

When we were considering this bug for the bounty (comment 32) we discovered that it was not fully fixed: nothing was done to prevent select options from bleeding through another site as you had noted in comment 26. The fixes only made selects harder to open and keep open.

Now what? We're 30+ comments into this bug and now we need a new testcase to show the part that wasn't fixed, and anyone coming to this bug would have to scroll 7 or 8 screens to find out what this bug is now "really" about. That's a mess and has a high failure rate when it comes to getting bugs fixed. It's also discouraged by our Bug Writing Guidelines (#5). As we explained in comment 32, we forked the unfixed part of this bug into bug 1909529. And then you filed bug 1909535 in addition (which is mostly a dupe but maybe a novel popup-blocker bypass -- haven't checked on that).

We are not going to reconsider the bounty decision in this bug because we have moved the non-duplicate parts to other bugs for clarity. If we missed something we're still not going to reconsider the bounty decision in this bug; file new bugs.

and therefore first part was addressed by Bug 1877969 (opened 2024-02-01), following the reporting of this issue (2024-01-22).

When bug 1877969 was filed is irrelevant.

• it was a required part of the fix for bug 1875354, for which you got a bounty.
• bug 1877969 was filed at the END of WHTWG standards body negotiations about how to fix a part of the HTML spec that led to negative outcomes wrt security. We knew about the issue long before that bug was filed in bugzilla. Reaching consensus amongst multiple browser companies is not quick.

off-topic bugzilla tip:
You shouldn't have to create manual links for comments and bugs: Bugzilla will auto-linkify them for you. As a bonus the links will have hover text showing the status of the linked bug. https://bmo.readthedocs.io/en/latest/using/tips.html#autolinkification

Comment 37

[Shaheen Fazim]

I saw the inconsistency (both in fix and report dates), so I just tried to see if I could avail the bounty to see how things would change, but it's alright for me.

I feel like my points are not being conveyed properly, but I don't wish to argue further. I understand that the bounty is not being considered.

Thanks again, Daniel, for the detailed explanation, and I appreciate your time in replying to my comment.