Closed Bug 1753339 (CVE-2023-32205) Opened 2 years ago Closed 1 year ago

Autofill prompt can render over browser UI and permission prompts, allows spoofing of browser UI


(Toolkit :: Autocomplete, defect, P2)




114 Branch
Tracking Status
firefox-esr102 113+ verified
firefox112 --- wontfix
firefox113 --- verified
firefox114 --- verified


(Reporter: bugzilla-mozilla, Assigned: emilio)



(Keywords: csectype-spoof, sec-high, Whiteboard: [fixed by bug 1826622][adv-main113+][adv-ESR102.11+])


(7 files, 1 obsolete file)

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.

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

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
  2. Press space or down arrow once.

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

  1. Navigate to
  2. (Same as first PoC)

PoC for permission prompt to cover "Block" button:

  1. Navigate to
  2. (Same as first PoC)

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

  1. Navigate to
  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.

Reporter credit: Alesandro Ortiz

Attached file autofill-ui-combo.html
Attached file autofill-setup-frames.html (obsolete) —
Attachment #9262028 - Attachment is obsolete: true

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.)

Component: Security → Form Autofill
Ever confirmed: true
Product: Firefox → Toolkit
See Also: → 1753341
Summary: Security: Autofill prompt can render over browser UI and permission prompts, allows spoofing of browser UI → Autofill prompt can render over browser UI and permission prompts, allows spoofing of browser UI
Group: firefox-core-security → core-security
Component: Form Autofill → Widget
Product: Toolkit → Core

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.

Group: firefox-core-security
Component: Widget → General
Product: Core → Firefox

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.

Group: core-security

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

Flags: needinfo?(sgalich)
Component: General → Autocomplete
Flags: needinfo?(sgalich)
Product: Firefox → Toolkit
See Also: → CVE-2021-38508
Flags: needinfo?(sgalich)
Blocks: 1753341
Flags: needinfo?(sgalich)

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?

Flags: needinfo?(enndeakin)

setConstraintRect should be called just before openPopupAtScreenRect to open the popup. The select element does this at

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

Flags: needinfo?(enndeakin)

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.

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.

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

Severity: -- → S3
Priority: -- → P3

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.

Flags: needinfo?(mak)

(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.

Severity: S3 → S2
Flags: needinfo?(mak)
Flags: needinfo?(enndeakin)
Flags: needinfo?(emilio)
Priority: P3 → P2

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?

Flags: needinfo?(emilio)

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.

Flags: needinfo?(enndeakin)

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

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

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)?

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.

Closed: 1 year ago
Duplicate of bug: CVE-2023-32212
Resolution: --- → DUPLICATE

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

Depends on: CVE-2023-32212
No longer duplicate of bug: CVE-2023-32212
Whiteboard: [fixed by bug 1826622]
No longer blocks: 1753341
Group: firefox-core-security → core-security-release
Assignee: nobody → emilio
Target Milestone: --- → 114 Branch
Whiteboard: [fixed by bug 1826622] → [fixed by bug 1826622][adv-main113+]
Whiteboard: [fixed by bug 1826622][adv-main113+] → [fixed by bug 1826622][adv-main113+][adv-ESR102.11+]
QA Whiteboard: [post-critsmash-triage]
Flags: qe-verify+

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.

Flags: qe-verify+ → needinfo?(emilio)
Flags: needinfo?(emilio)

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.

Attached file advisory.txt
Alias: CVE-2023-32205
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.