1753339 - (CVE-2023-32205) Autofill prompt can render over browser UI and permission prompts, allows spoofing of browser UI

Status: VERIFIED FIXED

(Toolkit :: Autocomplete, defect, P2)

Description

[Alesandro Ortiz]

Attachment: autofill-over-browser-ui.mp4

VULNERABILITY DETAILS
Pages with carefully-positioned input fields can cause the browser to render autofill prompts over the browser UI. This can be used to spoof the address bar, cover/spoof permission prompts, cover window controls, or for other malicious purposes that involve covering the browser UI.

Only a single keypress (space or down arrow) is needed to open the autofill prompt and initiate the spoof. In the permission prompt PoCs, this single keypress is also used to obtain the user activation to open the permission prompt.

VERSION
Firefox Version: 96.0.3 Stable (Build ID 20220126154723), 98.0a1 Nightly (Build ID 20220127094620)
Operating System: Windows_NT 10.0 19042

REPRODUCTION CASE
See attached video with recording of all PoCs.

The PoCs add arbitrary autofill entries using iframes containing forms (see autofill-setup-frame.html).

Note: In these basic PoCs, I assume the browser window is wide enough (1750px+ on my device) so the address bar and permission prompts are in an easily-predictable position. This is an implementation detail; a more advanced PoC can take into account narrower windows. You may need to adjust the position of the input fields on your device.

PoC for address bar spoof:
Prerequisite: Have at least one address in about:preferences#privacy -> Forms and Autofill -> Saved Addresses...

1. Navigate to https://alesandroortiz.com/security/firefox/autofill-ui-address-bar.html
2. Press space or down arrow once.

PoC for permission prompt to cover/spoof most of the prompt:

1. Navigate to https://alesandroortiz.com/security/firefox/autofill-ui-permission.html
2. (Same as first PoC)

PoC for permission prompt to cover "Block" button:

1. Navigate to https://alesandroortiz.com/security/firefox/autofill-ui-permission-button.html
2. (Same as first PoC)

PoC for address bar spoof + cover/spoof most of the permission prompt:

1. Navigate to https://alesandroortiz.com/security/firefox/autofill-ui-combo.html
2. (Same as first PoC)

For all PoCs:
Observed: Autofill prompt is rendered above browser UI, such as the address bar, permission prompts, and window controls.
Expected: Autofill prompt is rendered below browser UI, or is not rendered if there is no space to safely show.

CREDIT INFORMATION
Reporter credit: Alesandro Ortiz https://AlesandroOrtiz.com

Comment 1

[Alesandro Ortiz]

Attachment: autofill-ui-address-bar.html

Comment 2

[Alesandro Ortiz]

Attachment: autofill-ui-permission.html

Comment 3

[Alesandro Ortiz]

Attachment: autofill-ui-permission-button.html

Comment 4

[Alesandro Ortiz]

Attachment: autofill-ui-combo.html

Comment 5

[Alesandro Ortiz]

Attachment: autofill-setup-frames.html

Comment 6

[Alesandro Ortiz]

Attachment: autofill-setup-frame.html

Comment 7

[Andrew McCreight [:mccr8]]

The links in comment 0 work for me, though the attachments don't work as is. (I'm not sure why that is, though maybe trustedOrigin needs to be updated, and I'm not sure if the way the iframe is loaded would need to be changed, too.)

Comment 8

[Stephen A Pohl [:spohl]]

Although this may require a fix in widget code, Core:Widget isn't the right component to track this. If widget changes are required, we should file individual widget bugs for each platform. Going to try Firefox:General next.

Comment 9

[Andrew McCreight [:mccr8]]

The URL bar spoofing is a bit janky looking, but convincing enough, so I'll mark this sec-high. The variations show that this is a flexible technique.

Comment 10

[Andrew McCreight [:mccr8]]

Sergey, do you have any idea who might have the time and experience to investigate this? The URL bar spoof is concerning. Thanks.

Comment 11

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

Adding a few persons that may help.
Toolkit / Autocomplete is mostly about the autocomplete controller, that today is pretty much used only by autofill and select.

But here the problem seems to be with the result pane that somehow is drawn over the chrome area, that shouldn't really happen.
Neil, do you have any insight about which code is responsible to draw this panel?

Comment 12

[Neil Deakin]

setConstraintRect should be called just before openPopupAtScreenRect to open the popup. The select element does this at https://searchfox.org/mozilla-central/rev/570f6e5c06b6c8140f53bf104d785a18165212ab/toolkit/actors/SelectParent.jsm#300

We might also consider just adding this to openPopupAtScreenRect so that all callers will do this.

Comment 13

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

There's other uses of openPopupAtScreenRect that don't define a constraint, so it makes sense to enforce it directly in openPopupAtScreenRect.
it will be a little bit more verbose but then consumers can't ignore the need to set a constraint.
Actually I wonder if openPopupAtScreenRect could be cleaned up a bit to take a DOMRectReadOnly instead of the single properties, then it may be more compact.

Comment 14

[Emilio Cobos Álvarez (:emilio)]

Hmm, if we don't plan to allow these escaping from the content area, what's the point of rendering these on the parent process?

This looks somewhat similar to bug 1366818 which has a bit more discussion and context.

Comment 15

[Emilio Cobos Álvarez (:emilio)]

Ah, it was already on the see-also list :)

Comment 16

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

The severity field for this bug is set to S3. However, the bug is flagged with the sec-high keyword.
:mak, could you consider increasing the severity of this security bug?

For more information, please visit auto_nag documentation.

Comment 17

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #14)

Hmm, if we don't plan to allow these escaping from the content area, what's the point of rendering these on the parent process?

This looks somewhat similar to bug 1366818 which has a bit more discussion and context.

The autocomplete widget code is used by both chrome and content. I'm not sure whether it could be adapted to render in the appropriate context, someone who worked on porting it to e10s, or supporting form/autofill may chime in.
Bug 1366818 didn't end up moving rendering to content, since there were discussions about clipping by the viewport things in tiny iframes... Those same discussions would apply here if we'd render in content?

Neil, if we use setConstraintRect, is there any kind of clipping or will popups just be repositioned to fit inside the content area? I guess at that point the only concern would be tiny windows and likely we don't care that much about that case.

Emilio, how would you solve the concerns about clipping that were raised in bug 1366818? If there's no major clipping involved in it, it looks like Neil's suggestion may still be the best approach.

Comment 18

[Emilio Cobos Álvarez (:emilio)]

I guess setConstraintRect to the content area may be reasonable if we care about tiny iframes but not e.g., small windows or what not. As for "how would I solve it", seems kind of hard... That said, I can't repro any of the PoC, at least on Linux?

Comment 19

[Neil Deakin]

The popup will get flipped around its anchor point/rectangle it it doesn't fit where it is asked to go. If it still doesn't fit it will be pushed into place or clipped if needed. The exact mechanism is determined by the type of popup, the direction and the flip attribute.

Comment 20

[Alesandro Ortiz]

Hi all, has any work been done on this bug since last comment 8 months ago?

Comment 21

[Emilio Cobos Álvarez (:emilio)]

I think this has been fixed in bug 1826622 (at least the autofill popup case).

Comment 22

[Alesandro Ortiz]

Thanks Emilio, this bug and related bug 1753341 still repros in 112.0.1 Stable (Build ID 20230414125621), but does seem to be fixed in 114.0a1 Nightly (Build ID 20230421030443). New behavior is that autofill prompt is shown within the page contents instead of outside page contents. I've tested all PoCs for both bugs.

Can the team make sure this makes it into Stable as a security fix, along with any other relevant processes (such as marking this as fixed)?

Comment 23

[Emilio Cobos Álvarez (:emilio)]

Thanks for confirming. I can do the bug tweaking, and the patch is already in beta, but it was tagged as sec-moderate so probably won't be a dot-release driver.

Comment 24

[Daniel Veditz [:dveditz]]

Although the underlying flaw turned out to be fixable at the same spot, in theory an autofill dropdown created by chrome-privileged code might have had different behavior than HTML datalist or select elements created in a web content context. It's better to make this set of testcases "depend on" the patched bug and have this bug marked fixed and independently verified.

We should also fix this on affected ESR-102

Comment 25

[Catalin Sasca, Desktop QA [:csasca]]

I was able to reproduce the issue on Firefox 96.0.3 on macOS 13.3.1 by following the informations provided in Comment 0.

The issue is fixed on Firefox 113.0 and Firefox 114.0a1 (2023-05-02). Tests were performed on macOS 13.3.1, Ubuntu 22.04 and Windows 11.

It seems that although the fixed flag is set for ESR, I can reproduce the blocking popups on Firefox 102.11.0ESR, and by searching in treeherder I couldn't find the fix being pushed either.

Comment 26

[Emilio Cobos Álvarez (:emilio)]

It was uplifted to ESR here: https://bugzilla.mozilla.org/show_bug.cgi?id=1826622#c37

Comment 27

[Catalin Sasca, Desktop QA [:csasca]]

Thanks Emilio! Looked over 102.11.0ESR and although the popup is present it is shown within the page contents instead of outside page contents. Tests were performed on macOS 13.3.1, Ubuntu 22.04 and Windows 11.

Comment 28

[Tyson Smith [:tsmith]]

Attachment: advisory.txt