1423733 - about:logins pre-filters to show logins for domains which contain the page's domain as a substring

Status: VERIFIED FIXED

(Firefox :: about:logins, defect, P5)

Description

[Vít Šesták 'v6ak']

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20171114221957

Steps to reproduce:

1. Go to https://sourceforge.net/auth/do_login and save a password. (You don't have to save a correct password, that is, for this experiment, you can use random username and password.)
2. Visit https://urceforge.net/KVB7JRQ4GPSH5QUEPZGU37SR3A/ .
3. Hell, the site has changed a login form, so the password is not filled. Let's copy it from saved passwords. Go to “Page Information”, go to “Security”, click “View Saved Passwords” and copy the password.
4. Paste the password to the login form.


Actual results:

At step 3., password for a completely different site (i.e., https://sourceforge.net) was shown as a password saved for https://urceforge.net. This caused me to paste my password for https://sourceforge.net to a fraud site.

(Well, https://urceforge.net is not actually a fraud site, just my demo. It is intentionally on a private URL only.)


Expected results:

At step 3, Firefox should not have shown the password for https://sourceforge.net . Firefox should apply the same same-origin policy as on password filling.

Other variants of the attack include using http website where https should have been used. This makes such attack more powerful in local network, especially with http links in e-mail due to link trackers.

Severity estimate: This issue allows password leak with some considerable (but still plausible) user interaction. I believe this is either sec-high or sec-moderate.

Context: https://twitter.com/v6ak/status/938361839251087360

Tested with both FF 52.5.0 ESR and FF 57.0.

Side note: Theoretically, there is the same issue with cookies, but I don't see any practical security impact with cookies.

Comment 1

[:Gijs (he/him)]

This is kind of interesting. The filter just does substring matches, so you can put in "google" and it will show you any *.google.* passwords. Which has helped me in the past, and I definitely get annoyed regularly when I've filled in passwords on subdomain.foo.com and then need the password on othersubdomain.foo.com, and the prefilled string is too restrictive.

So while in theeeeeory, this could be used by substring-matching domains to try to spoof a password, it seems pretty far-fetched in practice... And I don't see a good way of warning the user without breaking any and all substring matching, including intentional attempts to do so.

The only vaguely sensible option I see is that ifff the string in the filter box includes a "." and a valid suffix, when matching the host column (but obviously not when matching against the password or username columns!), ensure that the password is saved for an exactly-matching domain or its subdomains. So "google" will find "googleusercontent.com" or whatever it is, but "google.com" will not. That would solve this issue, as far as I can tell, without breaking intentional use too much, though it'd be a bit painful to implement and some of the resulting behaviour might be user-surprising (e.g. after typing "google.", lots of stuff is visible (because no valid public suffix), then after "google.c" still lots of stuff, then after "google.co" everything disappears (as ".co" is a valid suffix) and then after "google.com" things re-appear...)

Another alternative would be somehow making the filter box behave differently when opened from the page info dialog and/or "fill in login" context menu.

Matt, thoughts?

Comment 2

[Paul Theriault [:pauljt] (no longer reading bugmail)]

I don't think this is a priority issue. From a security risk perspective, its sec-low at most, but I dont think its even that high. If the user has confused domains, they are already getting phished - changing the behavior of that risk scenario isn't going to better protect the user here. If anything we might try to show that the pre-filed filter is just that - a filter that can be modified. But we already show the full domains below so I don't think there is anything to do here as a priority. Maybe we revisit in the future when if/when we try to improve site information.

Comment 3

[Matthew N. [:MattN]]

(In reply to :Gijs from comment #1)
> Another alternative would be somehow making the filter box behave
> differently when opened from the page info dialog and/or "fill in login"
> context menu.

This is the idea that also came to my mind.

I agree with Paul that this isn't a priority given all the user interaction involved since we don't let you fill directly from the dialog.

Comment 4

[:Gijs (he/him)]

Can we open this up, then? I agree this is sec-low at most.

Comment 5

[Vít Šesták 'v6ak']

I'll describe alternative attack scenario and then respond to your comments.

The alternative scenario: Basic technical principle remains the same, user story differs.

0. User has a saved password on a high-profile website like https://sourceforge.net.
1. User registers at a low-profile website like https://urceforge.net/second-YXNAOFRGYEB5VT3VAKH6X2BP4A/ and saves password. Using iframe, the password is actually saved to another domain. (It could look less suspicious if the domain was something like “rge.ne”. Which is, by the way, a free domain at the time of writing this text. U just don't want to pay the price, because .ne domains are quite expensive…)
2. Next time the user visits the site, it prevents password autocomplete in some way. I have implemented a heavy hack of PoC quality for this, I am sure it could have been improved.
3. Since the user does not remember the password, she opens the Page Info, Security tab and then Saved Passwords for that website.
4. Only one password is shown there. But it is not the password user looks for…

This alternative scenario is not likely to make much suspicion:

* First, user operates on some low-profile website, being likely to less suspicious, even if it is an advanced user.
* Second, if I am shown only one saved password, I tend to copy this one without thinking much about it. (Remember, the password for attacker's website is saved for some unrelated domain, so it is not present there.)

Now, my reactions:

First, I believe we should follow the least surprise principle. Whenever security-related UI behaves unexpectedly, there is some room for bad end-user decisions or misunderstanding in actions that have security impact.

The leading dot proposal looks like a viable fix at first sight, but I have few points against it.

* It is not intuitive for non-tech users, the leading dot is going to look rather as an error.
* It does not allow distinguishing between HTTP and HTTPS.

Maybe it would be better to include protocol prefix instead of leading dot. It would be less surprising and it would allow to be consistent with password filling SOP in terms of autofilling.

> Another alternative would be somehow making the filter box behave differently when opened from the page info dialog and/or "fill in login" context menu.

My opinion on this idea depends on details. If two dialogs looks the same, they should behave the same. So, if it behaves a bit differently, it should look at least a bit differently in order not to be surprising. Maybe there should be a slightly different UI that also suggest other domains within the same SLD (considering domains like .co.uk as TLD and something.co.uk as SLD). This could cover cases like www.spotify.com vs. play.spotify.com vs. accounts.spotify.com.

On severity: Based on https://wiki.mozilla.org/Security_Severity_Ratings , it could fall under “Obtain confidential data from other sites the user is visiting or the local machine, …, requiring no more than normal browsing actions.”, which is sec-high. The only controversial part seems to be if this falls under “normal browsing actions”. This way of looking for a saved password seems to be natural for me, but I haven't performed user testing. If it is not “normal browsing actions”, it falls under “Client bugs that might have high or critical results but require the user perform unusual or complex actions to trigger.”, which is sec-moderate.

> If the user has confused domains, they are already getting phished

It depends on the point of view. Sure, user can prevent the attack this way. OTOH, a user that relies on the functionality working as advertised (so that Saved Passwords within Page Info is expected to show just passwords for the specific site and nothing else) can reasonably assume this behavior is safe. But it is not.

Moreover, in the alternative scenario (see above), user does not have to confuse domains.

Comment 6

[Vít Šesták 'v6ak']

It seems I have accidentally removed the “sec-low” keyword, so I am putting it back. Sorry for that.

How have I accidentally removed it? It was probably a race condition. I had started writing my comment before it was added, but I posted the comment after the keyword was added.

Comment 7

[Vít Šesták 'v6ak']

Just prolonged the urceforge.net domain.

Comment 8

[Vít Šesták 'v6ak']

I have read that Firefox will get new password manager – Lockbox.

Now, I am suggesting:

• Verify if Lockbox has the same flaw. If yes, address it there.
• If Lockbox resolves this issue, them mark it as resolved in the version where Lockbox appears.

I have tried to find related issue through https://bugzilla.mozilla.org/buglist.cgi?quicksearch=lockbox&list_id=14629021 , but I haven't find what I wanted. There are some more specific bugs (e.g., related to Lockbox for Android), but there is no generic-enough bug.

Comment 9

[Matthew N. [:MattN]]

We are planning to stop pre-filtering from the autocomplete menu once we are sure we are showing all relevant items there (bug 1598464).

Comment 10

[Matthew N. [:MattN]]

After bug 1598464 this now only applies to the Page Info dialog entry point and usage of that is so low that I don't think this is worth fixing.

Comment 11

[Cosmin Muntean [:cmuntean], Ecosystem QA]

Considering the fact that bug 1598464 is fixed and verified and based on comment 10, I will also mark this bug as verified.