1625391 - Login information for file: pages is stored globally for all of file:

Status: NEW

(Toolkit :: Password Manager, defect, P3)

Description

[梁国强]

Attachment: fox.html

Do you watch the video? Text doesn't describe the problem directly:

https://drive.google.com/open?id=12Oz9Pr9YM100Hki_cNOG1_GlJ8edsdXn

Comment 1

[:Gijs (he/him)]

I don't understand what issue you're trying to describe. If you save a password for file://, then we will fill that login+password on the file:// page. Why is this surprising / a security problem?

Comment 2

[梁国强]

If the user in the local opens an HTML page, and fill in the web page the user name and password and preserved, in the password manager will have a file:// website user name and password, the attacker to send another login page to victims, the victims in the local open the attacker's web page, file:// website user name and password before also leaked out

Comment 3

[:Gijs (he/him)]

(In reply to 梁国强 from comment #2)

If the user in the local opens an HTML page, and fill in the web page the user name and password and preserved, in the password manager will have a file:// website user name and password, the attacker to send another login page to victims, the victims in the local open the attacker's web page, file:// website user name and password before also leaked out

So this would only affect users who:

1. use a file:/// login page
2. save the password in the password manager
3. would download an attacker's page
4. then open the now-locally-stored attacker's page
5. then somehow either reuse the credentials for the "real" local login page elsewhere, or otherwise expose the "real" local login page to the attacker (ie there is some other hole allowing the attacker to actually use the credentials for something).

Those are quite a lot of limitations. I especially haven't really seen people do (1) in the first place; if the file: page is validating the password locally, the password offers very little security in the first place... Unless the local tool is accurately using 2-way encryption (ie while you could validate a password with a hash function, that wouldn't add security unless the credentials themselves are actually used for encrypting local data).

I expect we should start saving passwords for the full file: origin, though that'll add friction for users, especially if we stop filling the credentials stored under file://. I'd sooner make a change like that in a public bug.

Comment 4

[梁国强]

Can I get a reward?

Comment 5

[梁国强]

Can I get a reward?

Comment 6

[Firefox Bug Husbandry Bot]

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is P3 (Backlog,) indicating it has been triaged, the bug's Severity is being updated to S3 (normal.)

Comment 7

[梁国强]

我是否有资格获得赏金？

Comment 8

[Matthew N. [:MattN]]

I think we may have unintentionally fixed this (any possibly caused regressions for this edge case). I suspect bug 1513003 is what would have done that.

Andrei, do you have a chance to confirm with mozregression when this was fixed? Watch the video for steps but essentially if you save a login form to your computer such and open it in Firefox (which is via a file:///… URI) then this bug doesn't want the captured logins shared with a different local file.

Comment 9

[Andrei Purice]

Hey I managed to find a regression range here :

Last known bad build was : https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=10807c4612a86618222b01fd9e0124d03f28d3a3&tochange=34aa06cff443833e1e0bdb8759c98cf3c4b7bf7d

First known good build was : https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=10807c4612a86618222b01fd9e0124d03f28d3a3&tochange=319bbb220b30c8112d62d642ee7ddc2009e76c72

Found commit message:
Bug 1513003 - only allow child process to query logins for the current base domain

Comment 10

[Daniel Veditz [:dveditz]]

This bug is not eligible for our security bug bounty. We don't consider this a security bug.