610997 - (CVE-2020-26962) Username + Password Autofill allows Forced Login via Clickjacking

Status: RESOLVED FIXED

(Toolkit :: Password Manager, defect, P3)

Description

[Paul Stone]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12
Build Identifier: 

The Firefox password manager will auto-fill a user's username and password in a login form, even if the page is loaded an IFRAME. A malicious site could use a clickjacking attack to force a user to log into a particular site, and then peform some other attack the required the user to be authenticated.

Example: A user has stored their credentials for foo.com in the Firefox password manager. An attacker knows of a vunlerability (e.g. XSS, CSRF) in foo.com and creates a malicious page to which he lures the user. The page can (optionally) use bug #583889 to check if the user is logged into the site. If not, the attacker can load up foo.com/login#login_btn into a hidden iframe and get the user to click. Because Firefox has auto-filled the user's credentials, the user will unknowingly log into the site. The attacker can then exploit the particular vulnerability in the user's authenticated session.

Some sites, (e.g. Google) will focus the password field if they detect that the username has been filled in. In this case, a malicious site could automatically detect whether the credentials for that site were auto-filled or not. 

Safari is not vulnerable to this attack, as it does not autofill login forms inside iframes. IE is not vulnerable either, because it requires the user to first select their username from a drop-down list before auto-completing the password.

Reproducible: Always

Steps to Reproduce:
1. Save credentials for site in Password Manager
2. Load site in iframe on another domain
Actual Results:  
Username and password are prefilled

Expected Results:  
Credentials should not be prefilled

Comment 1

[Paul Stone]

Attachment: Simple Testcase

I'll whip up a fun and convincing PoC if this isn't a dupe.

Comment 2

[Daniel Veditz [:dveditz]]

This is basically a dupe. A fairly old one, too, currently getting some publicity in Jeremiah Grossman's current web security talk. Also, he suggests you can skip the "is the user logged in check" and just flush all their cookies first to make sure they're not (which doesn't work in Firefox 4).

Well, the "via clickjacking" might be new (maybe not, rings bells), but the underlying problem that Firefox promiscuously splats out your password is known, and can be used to silently attack any site with an XSS flaw. The flaw can be anywhere on the site, not limited to the login page since your XSS script can just create a new login form. bug 408531

We added a preference to get something like the IE behavior: set "signon.autofillForms" to false and you have to select your user name from an autocomplete drop-down before it will replay your password. Unfortunately it's not the default (it's apparently inconvenient and a bad experience, although I'm relatively happy with it), and there's no preference UI for the feature other than going to the raw "about:config" panel which no one's going to figure out. bug 359675 comment 25 maybe sums up one train of thought.

The "Account Manager" feature was going to save us in Firefox 4 by moving site authentication into the browser "chrome", but that feature got delayed to a future release.

Not pre-filling passwords in frames was a passing thought in bug 359675 comment 18.

I don't think the clickjacking aspect is novel enough to add user risk and warrant keeping this bug hidden.

Comment 3

[Jaroslav Škarvada]

The "signon.autofillForms=false" does good job, but for "signon.autofillForms=true", which is the default, couldn't it be improved by not autofilling the forms in frames (i.e. all frames or frames loading content from different domain then parents)? I.e. what the Safari does?

Comment 4

[Mathew Hodson]

Was this fixed by bug 786276? Maybe it should have been depending on that bug rather than blocking it.

Comment 5

[Sam Foster [:sfoster] (he/him)]

(In reply to Mathew Hodson from comment #4)

Was this fixed by bug 786276? Maybe it should have been depending on that bug rather than blocking it.

Yes, this should be fixed by bug 786276. The core of the STR:

1. Save credentials for site in Password Manager
2. Load site in iframe on another domain

..will no longer work when the other domain is cross-origin to the site loaded into the iframe.