825787 - Master password can be bypassed by replacing the current key3.db file with an old version from the same profile that has a known (e.g. blank) password

Status: RESOLVED WONTFIX

(Core :: Security: PSM, defect)

Description

[Username]

User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.95 Safari/537.11

Steps to reproduce:

Well first of all we need to open firefox profile folder and copy key3.db file and save it another folder. after that open firefox and set up master password after that u can browser save some website login details and save it. well at last just replace key3.db which one we coped at past and than run it again firefox, then press show password and u will see saved web page, username and password.

Comment 1

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Let me make sure I understand here:

The bug is that any old key3.db file from a profile can be used to decrypt the contents of everything protected by the master password, because when you change your master password, we only change the key inside key3.db that encrypts the SDR key, and we don't generate a new SDR key and re-encrypt all of your data with it.

I am pretty sure this is working as designed, so it isn't an implementation defect, but a limitation of the current design. And, it is part of a more general limitation of the design of Firefox, where if you can modify the contents of the user's profile, you can completely take over their browser; e.g. by installing malicious extensions. We rely on the operating system's authentication (e.g. OS account password) and filesystem protection mechanisms (e.g. NTFS file permissions) to prevent unauthorized modification of your user profile's files.

The benefit of the current design is that we can change your password without having to re-encrypt all of your data. This makes password changing easy to implement and makes it fast. It also means we don't have to re-sync all of your data, if you are using the Sync feature.

Also, it is well-known that the master password is protected very poorly. So, anybody can use FireMaster or a similar tool to crack your master password, even without having an old key3.db with a blank password.

We may be able to solve both this problem and the FireMaster problem as part of some effort to use the operating systems' protected keystore instead of NSS's on platforms that provide an OS-mediated keystore.

Comment 2

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

I suggest we remove the core-security flag from this bug. I will let another security-group member remove the flag if they agree.

Comment 3

[Kai Engert (:KaiE:)]

I don't think what you describe is a security flaw. However, I see a benefit in your proposal.

Let's say we'd switch to a different symmetric key, and re-encrypt all web site passwords that have been saved in the user's profile, would that be a sufficient remedy after your old storage and your old master password has been leaked?

No, it wouldn't, because the attacker having access to your old key3.db file probably has a copy of the other files from the same profile directory, too, which means, the attacker already can read your old passwords, too.

This is a security management issue. If you believe your old key storage and your old password has been compromised, the only remedy is to change everything, including the passwords to all services that have been remembered in Firefox, and to stop using all private keys for personal certificates that had  been protected by it (get them revoked, and get new personal certificates using new keys).

If we re-encrypted all stored information at the time of changing the master password, using a new symmetric key, only all the newly added passwords and all new private keys would be protected.

I'd see the re-encryption with a new symmetric key as a convenience feature. You would be able to change your stored passwords one after the other, by visiting services, and benefit of the ability to still have the old passwords remembered, while you change them to new passwords.

Because of the convenience aspect, allowing one to transition to a new key store one password at a time, I'd agree that re-encryption would be a helpful feature.

(As of today, the practical approach would be: Reset the master password, which essentially erases key3.db and stops you from accessing any of your stored passwords or old personal certificates.)

Comment 4

[Justin Dolske [:Dolske]]

I'm pretty sure there's some other bug floating around for this issue, but I didn't find it from a quick search. In any case, I'd agree this is a known shortcoming of the current design, but isn't a vulnerability. Web content can't get at these files, and if something/someone else does gain access you're already on a very slippy slope toward total pwnage (eg, your cookies and history are stored in the same directory).

Still, it would be nice to improve.

Comment 5

[Username]

(In reply to Justin Dolske [:Dolske] from comment #4)
> I'm pretty sure there's some other bug floating around for this issue, but I
> didn't find it from a quick search. In any case, I'd agree this is a known
> shortcoming of the current design, but isn't a vulnerability. Web content
> can't get at these files, and if something/someone else does gain access
> you're already on a very slippy slope toward total pwnage (eg, your cookies
> and history are stored in the same directory).
> 
> Still, it would be nice to improve.

Well than can u describe me what the point of the master password?

Comment 6

[Robert Relyea]

> Well than can u describe me what the point of the master password?

It protects the keys used to encrypt passwords. When you copied your key3.db, you effectively compromised that key, because you made what is essentially a plain-text copy of it.

If you delete your key3.db from the profile after you copied it, and repeat the steps, you will not be able to read the new passwords you save under that master password after you copy the old key3.db back because you will have lost access the key uses.

** Hack to get access to your old passwords while protecting new passwords---
  1) copy your key3.db out of your profile.
  2) delete your key3.db.
  3) set a master password.
  4) save a password.
  5) exit firefox.
  6) certutil --merge -d {firefox_profile_directory} --source-dir {directory_with_your_saved_key3.db}
 

You can now go back to firefox. You should be able to read all your passwords. If you now copy key3.db back to your profile directory you will only be able to see your old saved passwords, not ones saved after you set the master password.
-------------------------------


That being said, I see no issue and some benefit from having code that rekeys the passwords. The SDR code can handle more than one key. (clearly the average user couldn't perform the steps I described above). We are also missing code to backup and restore SDR keys like we can private keys.

bob

Comment 7

[Daniel Veditz [:dveditz]]

does not meet the bar for a bug bounty

Comment 9

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

(In reply to Robert Relyea from comment #6)
> > Well than can u describe me what the point of the master password?
> 
> It protects the keys used to encrypt passwords. When you copied your
> key3.db, you effectively compromised that key, because you made what is
> essentially a plain-text copy of it.

We can't realistically protect against this (except maybe by using OS-provided protected storage as Brian mentions in comment 1, but that's a large project that we're not going to allocate resources towards for the time being).