1491482 - [FG-VD-18-139] Mozilla Firefox Authentication Bypass Vulnerability Notification

Status: RESOLVED DUPLICATE of bug 1475775

(Core :: Security: PSM, defect)

Description

[Kushal Arvind Shah]

Attachment: FG-VD-18-139.zip.gpg

Subject: [FG-VD-18-139] Mozilla Firefox Authentication Bypass Vulnerability Notification

-------

Vulnerability Notification
Sept 14, 2018
Tracking Case #: FG-VD-18-139

Fortinet's FortiGuard Labs have discovered a security issue in your product Mozilla Firefox on September 14, 2018. We estimate its risk level is 4, on a scale of 1 (lowest) to 5 (highest), in terms of its impact. Please advise of the appropriate contact person in your company to handle this issue.

Fortinet's research remains ethical at all times, and we therefore strive to Responsible Disclosure. Fortinet vulnerability disclosure policy can be found at https://fortiguard.com/zeroday/responsible-disclosure. 

For this particular issue, we will wait until October 14, 2018 to post an advisory on our website (https://fortiguard.com/zeroday) and/or any other publication form (e.g. conference talk, demo, podcast, etc). 

We might publish *earlier* than that date only if:

1) Public proof of concept code is released, increasing the danger of the vulnerability being exploited in the wild;
2) Or you patched or updated the vulnerability - a positive fact we'll be happy to mention.

In the case you agree to patch this vulnerability and need more time, we are willing to delay publication to 90-days upon request. 

Fortinet will use reasonable efforts to communicate a schedule of planned mediums, including conferences with the appropriate stakeholders within the affected company.

Our security researchers work on your product or service either because it is popular and/or interesting, so please take this positively. This research is done free of charge for you, although our researchers will appreciate being mentioned in a Hall of Fame or bug bounty if any. Threats to our security researchers are not acceptable and will be dealt with by our Legal team.

We look forward to working closely with you to resolve this issue. If you wish to switch to confidential emails, you may pick up our PGP key on https://fortiguard.com/secresearch-pgpkey.


Kind regards,

Kushal Arvind Shah.
Security Researcher,
Fortinet's FortiGuard Labs.

Type of Vulnerability & Repercussions:
Authentication Bypass

Affected Products:
  Mozilla Firefox Quantum version: 62.0.0
  

Upcoming Advisory Reference:
http://www.fortiguard.com/advisory/UpcomingAdvisories.html

Credits:
This vulnerability was discovered by Kushal Arvind Shah of Fortinet's FortiGuard Labs.

Proof of Concept & Additional Information:
  We tested it on following platform: 
    Windows 7 Pro SP1 
	
Mozilla Firefox Quantum contains a vulnerability that could allow an attacker to bypass the Master Password Security Feature on the targeted system and gain access to all the saved usernames & passwords. This vulnerability exists due to the way any secondary Firefox installation can access the saved logins of any other primary Firefox installation on the same system, even if they are protected by a Master Password. 

This vulnerability can be leveraged by an attacker to gain access to all saved credentials on the target system. 

OS: Windows 7 SP1

Steps to reproduce: -

1. Install the Firefox Browser using default installation settings.

2. Save several websites (eg. gmail, github, yahoo, facebook, etc.) login credentials within the previously installed (installed in Step 1) Firefox Browser. 

3. Set a Master Password to the previously installed Firefox Browser, so as to protect all the other saved login credentials. Also notice that the "Use Master Password" option is now ticked.

4. Download another Firefox Installation Setup from the mozilla website.

5. Install the other Firefox Setup (downloaded in Step 4) and install it to a custom path on the system.

6. Launch the new Firefox browser (installed in Step 5) and go to Security -> Saved Logins

7. Notice, that we are able to see all the saved logins of the other Firefox Browser and also notice that the "Use Master Password" option is un-ticked.

Note: This Vulnerability works in all the latest Firefox Versions.

Comment 1

[:Gijs (he/him)]

(In reply to Kushal Arvind Shah from comment #0)
> 3. Set a Master Password to the previously installed Firefox Browser, so as
> to protect all the other saved login credentials. Also notice that the "Use
> Master Password" option is now ticked.

Have you actually gone through the first 3 steps with Firefox 62, or with an earlier version? Can you confirm that at that point there is no `key3.db` file in the user's profile directory? (see this known bug for context, fixed in Firefox 61: https://bugzilla.mozilla.org/show_bug.cgi?id=1475775 )

> 4. Download another Firefox Installation Setup from the mozilla website.
> 
> 5. Install the other Firefox Setup (downloaded in Step 4) and install it to
> a custom path on the system.
> 
> 6. Launch the new Firefox browser (installed in Step 5) and go to Security
> -> Saved Logins

At this point, I guess the browser from step 1/2/3 is still open? That will mean you won't actually start the new Firefox instance, you just opened a new window in the Firefox copy that was already running, where you've already input the master password, and therefore have access to the passwords.

Please can you confirm if you're able to reproduce if both installs are 62 or later, and with the first install fully shut down (verifying no processes remain running) ?

Comment 2

[Kushal Arvind Shah]

Hello Gijs, Ryan, Mozilla/Firefox Product Security Team,

Good Evening.

Firstly, I would like to thank you for the quick response, I sincerely appreciate it.

Secondly, following are the responses to your questions:-

Question from MozTeam: Have you actually gone through the first 3 steps with Firefox 62, or with an earlier version? Can you confirm that at that point there is no `key3.db` file in the user's profile directory? 

Answer: So, the first 3 Steps were done using the latest FireFox Quantum 60.2.0ESR version. And 'Yes' there is a 'key3.db' file in the user's profile directory.

The first 3 steps were mentioned just to replicate a regular victim user's environment wherein the user installs Firefox and saves logins and sets up a master password for security reasons.

Question from MozTeam: At this point, I guess the browser from step 1/2/3 is still open? That will mean you won't actually start the new Firefox instance, you just opened a new window in the Firefox copy that was already running, where you've already input the master password, and therefore have access to the passwords.

Please can you confirm if you're able to reproduce if both installs are 62 or later, and with the first install fully shut down (verifying no processes remain running) ?

Answer: NO, the First Browser from Step 1/2/3 is 'Not' open. All the parent/child processes for that browser are closed. Task Manager shows no running firefox processes. In fact, in one successful attempt at this Vulnerability's reproduction, the system was also restarted before Step 4 to ensure its a new process.

Also for Step 4,5,6 I used another Firefox version namely version 52.9.0ESR (just to cause less confusion, even though they are installed at different locations).

Kindly let me know if anything else is needed off me for the same.

Thanking You,

Yours Sincerely,
Kushal Arvind Shah.
Security Researcher | Fortinet's FortiGuard Labs.

Comment 3

[:Gijs (he/him)]

(In reply to Kushal Arvind Shah from comment #2)
> Question from MozTeam: Have you actually gone through the first 3 steps with
> Firefox 62, or with an earlier version? Can you confirm that at that point
> there is no `key3.db` file in the user's profile directory? 
> 
> Answer: So, the first 3 Steps were done using the latest FireFox Quantum
> 60.2.0ESR version.

Uh, are you sure? Because:

> And 'Yes' there is a 'key3.db' file in the user's profile
> directory.

I don't believe there should be a key3.db file if the profile was created by Firefox 60.2 esr. Can you clear %APPDATA%\Mozilla\Firefox (this will remove all Firefox data, but not the application) and retry your steps?

Comment 4

[:Gijs (he/him)]

(In reply to Kushal Arvind Shah from comment #2)
> Also for Step 4,5,6 I used another Firefox version namely version 52.9.0ESR
> (just to cause less confusion, even though they are installed at different
> locations).

Why does comment #0 say that you used Firefox 62 and "latest Firefox versions" are vulnerable, when you used 60.2esr and 52.9 esr?

Please retest on a clean profile using only recent versions.

Comment 5

[Kushal Arvind Shah]

(In reply to :Gijs (he/him) from comment #3)
> (In reply to Kushal Arvind Shah from comment #2)
> > Question from MozTeam: Have you actually gone through the first 3 steps with
> > Firefox 62, or with an earlier version? Can you confirm that at that point
> > there is no `key3.db` file in the user's profile directory? 
> > 
> > Answer: So, the first 3 Steps were done using the latest FireFox Quantum
> > 60.2.0ESR version.
> 
> Uh, are you sure? Because:
> 
> > And 'Yes' there is a 'key3.db' file in the user's profile
> > directory.
> 
> I don't believe there should be a key3.db file if the profile was created by
> Firefox 60.2 esr. Can you clear %APPDATA%\Mozilla\Firefox (this will remove
> all Firefox data, but not the application) and retry your steps?

So, there is a 'key3.db' file and a 'key4.db' file as well. I believe the key3.db file is present due to the Firefox auto updates. 

Are you able to reproduce this issue? 

If not, one guaranteed way to reproduce this issue is to install https://ftp.mozilla.org/pub/firefox/releases/52.9.0esr/win64/en-US/Firefox%20Setup%2052.9.0esr.exe and use it as a normal user and save credentials and then set master password. On subsequent restart of Firefox browser, it will auto-update to version 60.2.0ESR.

Then you could re-install the older version again on a custom path and get the saved logins without the master password.

Thanks,
~ Kushal.

Comment 6

[Kushal Arvind Shah]

(In reply to :Gijs (he/him) from comment #4)
> (In reply to Kushal Arvind Shah from comment #2)
> > Also for Step 4,5,6 I used another Firefox version namely version 52.9.0ESR
> > (just to cause less confusion, even though they are installed at different
> > locations).
> 
> Why does comment #0 say that you used Firefox 62 and "latest Firefox
> versions" are vulnerable, when you used 60.2esr and 52.9 esr?
> 
> Please retest on a clean profile using only recent versions.

Yes, Latest Firefox Quantum ESR version 60.2.0. Apologies if there was any confusion with regards to the version between the ESR and other build channels.

Comment 7

[:Gijs (he/him)]

(In reply to Kushal Arvind Shah from comment #5)
> So, there is a 'key3.db' file and a 'key4.db' file as well. I believe the
> key3.db file is present due to the Firefox auto updates. 

The key3.db file was created by 52. The key4.db file was created by Firefox 60.2 esr (or any other version more recent than Firefox 58). We didn't delete the key3 file because people downgrade, and losing all your passwords when downgrading is obviously not great.

> If not, one guaranteed way to reproduce this issue is to install
> https://ftp.mozilla.org/pub/firefox/releases/52.9.0esr/win64/en-US/
> Firefox%20Setup%2052.9.0esr.exe and use it as a normal user and save
> credentials and then set master password. On subsequent restart of Firefox
> browser, it will auto-update to version 60.2.0ESR.

These steps match bug 1475775, which I already linked previously. We've already addressed this in later (non-ESR) versions of Firefox, and the bug is public. We haven't specifically tried to address this on ESR releases yet, as it requires local attacker privileges so it isn't high severity, and the same fix applied on regular releases isn't the right fix for ESR.

> Then you could re-install the older version again on a custom path and get
> the saved logins without the master password.

If you set the master password in key4.db when the passwords are also stored in the key3.db file without the master password, then that's expected.

Comment 8

[Kushal Arvind Shah]

(In reply to :Gijs (he/him) from comment #7)
> (In reply to Kushal Arvind Shah from comment #5)
> > So, there is a 'key3.db' file and a 'key4.db' file as well. I believe the
> > key3.db file is present due to the Firefox auto updates. 
> 
> The key3.db file was created by 52. The key4.db file was created by Firefox
> 60.2 esr (or any other version more recent than Firefox 58). We didn't
> delete the key3 file because people downgrade, and losing all your passwords
> when downgrading is obviously not great.

Ok, so instead of deleting 'key3.db' you could always re-encrypt it similar to 'key4.db' or in a different way. That way no user is losing all their passwords and at the same time, is being safe against this Vulnerability.
 
> > If not, one guaranteed way to reproduce this issue is to install
> > https://ftp.mozilla.org/pub/firefox/releases/52.9.0esr/win64/en-US/
> > Firefox%20Setup%2052.9.0esr.exe and use it as a normal user and save
> > credentials and then set master password. On subsequent restart of Firefox
> > browser, it will auto-update to version 60.2.0ESR.
> 
> These steps match bug 1475775, which I already linked previously. We've
> already addressed this in later (non-ESR) versions of Firefox, and the bug
> is public. We haven't specifically tried to address this on ESR releases
> yet, as it requires local attacker privileges so it isn't high severity, and
> the same fix applied on regular releases isn't the right fix for ESR.

So, since the Vulnerable Firefox Version is different, it cannot be a duplicate, especially more so coz of your comment #41 in report https://bugzilla.mozilla.org/show_bug.cgi?id=1475775 . Also, for this Vulnerability, Local Attacker privileges are required in any version ESR/nightly/stable/non-ESR/etc. so based on simple logic, that cannot be a valid reason for addressing/fixing non-ESR builds and not addressing/fixing ESR builds.

> > Then you could re-install the older version again on a custom path and get
> > the saved logins without the master password.
> 
> If you set the master password in key4.db when the passwords are also stored
> in the key3.db file without the master password, then that's expected.

Since the Vulnerable versions of Firefox are different and also coz of comment 41 in https://bugzilla.mozilla.org/show_bug.cgi?id=1475775, I do not believe this is a Duplicate issue and nor is it Resolved coz the Vulnerability does still exist in the Latest Updated FireFox Quantum ESR version.

Nevertheless, if you believe this issue is Fixed and is a Duplicate, then we would like to immediately proceed with Public Disclosure of the same.

Eagerly awaiting your response.

Thanks,
~ Kushal.

Comment 9

[:Gijs (he/him)]

(In reply to Kushal Arvind Shah from comment #8)
> (In reply to :Gijs (he/him) from comment #7)
> > (In reply to Kushal Arvind Shah from comment #5)
> > > So, there is a 'key3.db' file and a 'key4.db' file as well. I believe the
> > > key3.db file is present due to the Firefox auto updates. 
> > 
> > The key3.db file was created by 52. The key4.db file was created by Firefox
> > 60.2 esr (or any other version more recent than Firefox 58). We didn't
> > delete the key3 file because people downgrade, and losing all your passwords
> > when downgrading is obviously not great.
> 
> Ok, so instead of deleting 'key3.db' you could always re-encrypt it similar
> to 'key4.db' or in a different way. That way no user is losing all their
> passwords and at the same time, is being safe against this Vulnerability.

That's a more difficult fix, and it'd require a different patch than what we used on regular release versions of Firefox.

> > > If not, one guaranteed way to reproduce this issue is to install
> > > https://ftp.mozilla.org/pub/firefox/releases/52.9.0esr/win64/en-US/
> > > Firefox%20Setup%2052.9.0esr.exe and use it as a normal user and save
> > > credentials and then set master password. On subsequent restart of Firefox
> > > browser, it will auto-update to version 60.2.0ESR.
> > 
> > These steps match bug 1475775, which I already linked previously. We've
> > already addressed this in later (non-ESR) versions of Firefox, and the bug
> > is public. We haven't specifically tried to address this on ESR releases
> > yet, as it requires local attacker privileges so it isn't high severity, and
> > the same fix applied on regular releases isn't the right fix for ESR.
> 
> So, since the Vulnerable Firefox Version is different, it cannot be a
> duplicate, especially more so coz of your comment #41 in report
> https://bugzilla.mozilla.org/show_bug.cgi?id=1475775 .

It's the same fundamental issue. We leave a file on disk that isn't encrypted with the MP, even when a user subsequently sets a MP. bug 1475775 has already explicitly set 60esr as affected by that same issue, and then set the status as wontfix (which means we won't be using the same fix we used for Firefox 61 (non-esr) to address this issue in esr builds).

We only use 1 bug per issue, even if the issue affects multiple versions of Firefox. Re-reporting bugs that are fixed in Firefox 61 or later because they haven't been fixed in 60esr isn't normally helpful.

> Also, for this
> Vulnerability, Local Attacker privileges are required in any version
> ESR/nightly/stable/non-ESR/etc. so based on simple logic, that cannot be a
> valid reason for addressing/fixing non-ESR builds and not addressing/fixing
> ESR builds.

Our ESR FAQ ( https://www.mozilla.org/en-US/firefox/organizations/ ) states:

> Maintenance of each ESR, through point releases, is limited to
> high-risk/high-impact security vulnerabilities and in rare cases
> may also include off-schedule releases that address live security
> vulnerabilities.

bug 1475775 is marked low severity (see the sec-low keyword in the keywords field). As indicated in the FAQ quote, not all low-security issues fixed in "regular" versions of Firefox are fixed in esr - it depends on the issue and how easy it is to backport the patches used to fix the issue on regular release versions of Firefox.

This also means that, more generally, if you're going to do security research on Firefox, it would be much more valuable to do so on current versions of release, rather than ESR. In the case of this report, you're relying on Firefox 52 esr, which is nearly 18 months old (and no longer supported), to reproduce. That doesn't mean you can never report anything important, but it reduces your chances.

> coz of comment 41 in https://bugzilla.mozilla.org/show_bug.cgi?id=1475775, I do not
> believe this is a Duplicate issue and nor is it Resolved coz the
> Vulnerability does still exist in the Latest Updated FireFox Quantum ESR
> version.

comment 41 is repeating what was discussed much earlier in the bug (e.g. bug 1475775 comment 21), and asking if we decided not to fix the issue on esr at all, or if not, where we're tracking a fix for esr.

> Nevertheless, if you believe this issue is Fixed and is a Duplicate, then we
> would like to immediately proceed with Public Disclosure of the same.

As I've said, I *don't* think it's fixed on esr... but we're aware of that. It says so in bug 1475775. We don't think it's high severity, and the bug of which I marked this one as a duplicate is already publicly viewable. It also appeared in our advisories for Firefox 61: https://www.mozilla.org/en-US/security/advisories/mfsa2018-20/#﷒0﷓ .