Open Bug 1608687 Opened 11 months ago Updated 10 months ago

Master password prompt gives the appearance of a security check, but can be bypassed once it was already unlocked

Categories

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

74 Branch
defect

Tracking

()

People

(Reporter: mail, Unassigned)

Details

(Keywords: sec-low, Whiteboard: Start with comment 3 [passwords:master-password])

Attachments

(1 file)

I installed Firefox 73 Beta and i am still able to bypass bug 1584126 as the following video shows:
https://drive.google.com/file/d/1ArFUfzErXyTAmrq8JbQDRaN5zc489SZI/view?usp=sharing

Code:

window.addEventListener("AboutLoginsLoginSelected", event => {
    console.log(event);
    alert(event.detail.username + ':' + event.detail.password);
});

As you said patching like bug 1584126 does not solve the underlying issue.

Status: RESOLVED → UNCONFIRMED
Flags: sec-bounty- → sec-bounty?
Resolution: DUPLICATE → ---
Summary: Master password prompt gives the appearance of a security check, but it is easy to bypass. → Master password prompt gives the appearance of a security check, but it is easy to bypass (even after bug 1584126)
Whiteboard: Start with comment 3

Matt: more evidence we should just stop playing whack-a-mole and just implement bug 1592954

Flags: needinfo?(MattN+bmo)
Status: UNCONFIRMED → NEW
Ever confirmed: true

Yes with this PoC shown patching like it has been done in bug 1584126 does not solve the issue. You will find ways like i did to receive access to the password property.
There are different solutions:

But from a UX point of view noone would like bug 1592954.

I want to suggest implement it like the following and keep UX great:

  • if a Master Password is not set nothing changes. The password property for login-item is still filled.
  • if a Master Password is set the password property should not be loaded to login-item. leave it empty.

So if someone clicks on "Show Password" and the MP prompt appears
THEN you should fill the password property AFTER the Master Password is correctly entered.

Example:

loginItem.password = LoginHelper.getPasswordFromLogin(loginItem, masterPassword)

Fon't forget to destroy the password property when someone clicks on another LoginItem or set a Timeout.

At the moment the promptForMasterPassword is obligatory because the password property is already loaded to LoginItem. That is the cause of this problem.

What you can't do with that solution anymore:

  • without entering a MP filtering for passwords (what would be the correct way in my opinion because this functionality also leaks used special chars and so on)
  • show the actual length of a password (like the password-display field does it at the moment). You should use a fixed length like other password managers do.

(In reply to Javan from comment #3)

As you said patching like bug 1584126 does not solve the underlying issue.

It wasn't trying to address this case so what you're showing is a known limitation, not worthy of a bounty IMO. See below (emphasis added):

(Quoting Matthew N. [:MattN] from bug 1584126 comment #29)

Requiring the MP before loading the page was too big of a change for something we would ideally uplift and would be inconsistent with how the old password management UI worked and how Chrome works so for now I'm just addressing the specific issue in this bug summary: access to the plaintext password via the password input element in the Inspector of developer tools before re-entering the master password. There will still be other ways to get the plaintext out of the page, just like the same can be done from the Browser Console/Toolbox once MP has already been unlocked.

The point of bug 1584126 was to get us back to the state before about:logins, where you couldn't trivially find the password via the Inspector tool. Once the master password is unlocked, it's expected that you can run code in a privileged page to access the passwords again. I agree that would could make this limitation more clear in Preferences but we are in the process of overhauling the feature so I don't want to invest more effort into it now other than fixing regressions (like bug 1584126).

Flags: needinfo?(MattN+bmo)
Priority: -- → P5
Whiteboard: Start with comment 3 → Start with comment 3 [passwords:master-password]
Version: 72 Branch → 74 Branch

(In reply to Matthew N. [:MattN] from comment #7)

It wasn't trying to address this case so what you're showing is a known limitation, not worthy of a bounty IMO. See below (emphasis added):

The title of this bug is still pretty accurate: "Master password prompt gives the appearance of a security check, but it is easy to bypass". I did not know you knew about that bad design first. But after looking into the code I also realized that the security problem must have been aware of the development during the implementation. But better to look ahead now.

I thought and everybody else thinks that if there is a security gateway the the crown jewels behind it would be protected. And we all still know the behavior of the old password manager and how the master password provided protection there.

When i took a deep dive into code from about:logins and added my explanation I had expected an implementation like that I have explained in comment #5. Give it a try and maybe consider it. That would have been better than hiding the password field (like bug 1584126) and the issue would be already out of our minds.

I'm surprised that exactly the same scenario already occurred in the old Password Manager and that there was CVE-2019-11733 for it. If you read the CVE description the attack scenario is nearly the same. Is there a reason why no CVE-ID has been assigned for this same issue yet?
Source: https://www.mozilla.org/en-US/security/advisories/mfsa2019-24/#CVE-2019-11733

When a master password is set, it is required to be entered again before stored passwords can be accessed in the 'Saved Logins' dialog. It was found that locally stored passwords can be copied to the clipboard thorough the 'copy password' context menu item without re-entering the master password if the master password had been previously entered in the same session, allowing for potential theft of stored passwords.

In my PoC you can access the passwords like shown in comment #3 without re-entering the master password.
Tested Versions:
Firefox 73 beta (affected)
Firefox 72 (affected)

I hope to be still considered for a bounty because I clearly marked the wrong bugfixing path by providing a solid Bypass before it comes to release. I also named the root cause of this problem first and made a proposal how it could be fixed (comment #5).

Flags: needinfo?(MattN+bmo)
Keywords: sec-low

(In reply to Javan from comment #8)

When i took a deep dive into code from about:logins and added my explanation I had expected an implementation like that I have explained in comment #5. Give it a try and maybe consider it. That would have been better than hiding the password field (like bug 1584126) and the issue would be already out of our minds.

We already had plans to make the decryption of the password field lazy as it's both a security and performance win. It's just not a high priority given that less than 1% of users use a Master Password.

Flags: needinfo?(MattN+bmo)
Flags: sec-bounty? → sec-bounty-

The stat, as only 1% use a master password is ridiculous. We are talking about a password manager that has been integrated into a browser and synchronizes all my passwords between my devices. The requirements for a good password manager should be more than just a 1%.

Could you please make this bug public, as i would like to publish a write up about it on Monday.

(In reply to Javan from comment #10)

The stat, as only 1% use a master password is ridiculous. We are talking about a password manager that has been integrated into a browser and synchronizes all my passwords between my devices. The requirements for a good password manager should be more than just a 1%.

See Why aren‘t physically-local attacks in Chrome’s threat model? for reasons why trying to protect against local attacks isn't very useful in many cases. As long as the browser is able to autofill your password without a prompt because it is unlocked, an attacker can also access those same passwords. How did you think the browser was able to autofill passwords after the initial unlock without re-entering the master password?

It sounds like what you really want is to lock the master password after some time. You can manually lock it via about:preferences => Security Devices => Software Security Device => Log Out. Then the master password would be required to be re-entered the next time a password needed to be decrypted such as the scenario you described in this bug.

To be clear, I acknowledge that this could be concerning for users who expect the master password to get re-locked but given the issues of local attacks on desktop operating systems, the main point of the master password now is to reduce the ease of local snooping, not to stop a determined local attacker since there are many ways to access the protected data from from outside of Firefox on desktop OSs (e.g. reading from memory, spoofing a master password dialog, etc.). See bug 266778 comment 1 for a request for having a timeout for master password.

Could you please make this bug public, as i would like to publish a write up about it on Monday.

It seems like the blog post will boil down to "once a password manager is unlocked and remains unlocked, passwords can be retrieved without further entries of the master password" which doesn't sound very novel. See https://lwn.net/Articles/714473/ for where this has already been documented.

Group: firefox-core-security
Summary: Master password prompt gives the appearance of a security check, but it is easy to bypass (even after bug 1584126) → Master password prompt gives the appearance of a security check, but can be bypassed once it was already unlocked
You need to log in before you can comment on or make changes to this bug.