1715334 - Firefox Windows Installer Local Privilege Escalation

Status: RESOLVED WONTFIX

(Firefox :: Installer, defect, P2)

Description

[Robert]

Attachment: Advisory.pdf

See the attached PDF advisory.

For associated files, see: https://drive.google.com/drive/folders/18J--nE8_RULx9iEPbL3DqBzAW29BkFan?usp=sharing.

Comment 1

[Daniel Veditz [:dveditz]]

This honestly might be as-designed -- if you put it in a common folder rather than in a personal one maybe you intended to share it? Dunno, bouncing to the install team.

Comment 2

[Robert]

Hi Daniel,

Thanks for taking a look at this.

Even if the Firefox installation is meant to be shared, that doesn't mean arbitrary users should be able to modify the integrity of the installation right? For example, you can't just directly overwrite the Firefox executable. We've reported a similar vulnerability to some other popular applications like Erlang, RabbitMQ, Atlassian Confluence, etc, and they've treated it as not-intended, updating their installer configurations.

In our experience, insecure directory permissions is a pretty common vector for local privilege escalations on Windows, and we think it represents a legitimate security concern.

Comment 3

[ecbftw]

Hello,

I've been helping Robert with his research. The way I look at this, is if the software's installer is giving the user the option to change the installation directory AND it is creating that directory for them, then there really is an expectation of a safe deployment. I don't think it is reasonable to expect the general public to understand windows filesystem permissions and its inheritance model, and even if they do, how would they know they need to go change permissions after installation? There's no warning given. (Note that I don't think just adding a warning is a good idea here... Just trying to consider things from the user's perspective.)

Considering the root cause, I could definitely get behind an argument that a third-party installer framework is to blame, if it is the one handling this step and using bad defaults. But of course this doesn't matter to the end user... they just see Firefox is putting them at risk to a local privilege escalation.

HTH,
tim

Comment 4

[ecbftw]

Any update on this?

Comment 5

[:Gijs (he/him)]

Rachel, is this on someone's radar?

Comment 6

[Robert]

It's also worth noting that a very similar issue was reported to and fixed by NodeJS (https://hackerone.com/reports/1211160).

Comment 7

[Rachel Tublitz [:rachel]]

(In reply to :Gijs (he/him) from comment #5)

Rachel, is this on someone's radar?

Thanks for flagging me - I was out last week, just got back.

We'll discuss as a team tomorrow and determine a priority at that time. I'll leave the ni? here for myself to come back and provide an update after that.

Comment 8

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

For reference, Erlang handled this in their NSIS installer via calls to icacls, Node's MSI installer explicitly sets permissions on the directory when creating it.

Comment 9

[Nick Alexander :nalexander [he/him]]

We discussed this in the Install/Update team meeting. I'll summarize here. We agree that there is a risk of local privilege escalation, and we intend to mitigate it in some manner. We already restrict to updating only installations in c:/Program Files to avoid similar attacks (see, for example, Bug 1643199), so this seems prudent.

But we're not yet clear on how we feel about the real world implications of the issue. Installing with elevation to a weak parent directory, one that causes the child install dir to inherit permissive permissions, is fairly far from the beaten path, and we're wary of monkeying with ACLs, which can always introduce problems. We'll talk more with our security team to assess this risk.

In a different direction, I personally wonder what happens if we install to an existing directory with a DLL already present. I know we support pave-over installs to an existing location, but I'm not sure if we purge said location -- let alone modify its permissions.

Comment 10

[ecbftw]

Thanks for the update. When it comes to privilege inheritance in NTFS, that's the default behavior of Windows. If the Firefox installer is creating a new folder for the user, I believe it is always going to inherit the parent directory's permissions by default. In this specific case (Firefox creating a fresh directory for the user), I think it should be up to the installer to break the inheritance chain and set reasonable permissions.

The case of an existing directory with already malicious files... that's really interesting and we hadn't really considered it. One option would be to have the installer warn the user that all existing files will be purged, and then just do that and fix permissions like normal. However, it is a bit heavy-handed. Another option would be to not delete anything that isn't going to be overwritten anyway, but then... should permissions change or should the user just be told they are taking their security into their own hands? What kind of warning could you give the user that actually is meaningful to the typical person? A third option would be to forbid the user from installing in an existing directory. Seems to me options 1 or 3 are easiest to explain to the lay person while remaining safe.

Happy to discuss other ideas.

Comment 11

[Nick Alexander :nalexander [he/him]]

Kirk -- have you an opinion on the security risk of this report? I know you have some experience with Windows directory permissions.

Comment 12

[Robin Steuber (they/them) [:bytesized]]

I'm not sure precisely what fix is being proposed for this, but I'm nervous. My biggest concern is that I believe this would break Firefox's ability to self-update. We currently only allow the Mozilla Maintenance Service to be used to update installations in the Program Files directory. Any installation outside of that directory can only be updated if Firefox has the necessary permissions to update itself. The security implications of breaking update are, I believe, more significant than the security implications of the existing permissions.

If we do make this change, I would strongly urge that we set the proper permissions at directory creation time rather than after the directory exists. See Bug 1551913 for an example of how changing directory permissions while elevated can be problematic.

@agashlin - Since you are assigned to this, could you please let me know how we are going to avoid breaking self-update if we are going to go through with this?

Comment 13

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

If I understand correctly, for this to be a vulnerability it requires:

1. The user specifies a directory (running the full installer manually and either specifying a path on the command line or when customizing in the install UI),
2. With inherited broad permissions
3. Not intending that access to the Firefox install
4. In a multi-user scenario.

This seems improbable, though if there was an easy fix it'd be fine for defense-in-depth. But it's always a little tricky managing directory permissions, especially with an app that needs to be able to update itself, so I'm looking for a reason to not deal with it here.

This can't give a SYSTEM escalation like Erlang: We always install the maintenance service to a fixed location under Program Files, and we don't allow it to interact with installations outside of Program Files (since bug 1643199).

Unlike Node we don't add the install dir to PATH, so it doesn't automatically lead to PATH pollution.

Kirk answered as I was writing this up, so there's a little redundancy. I am also concerned about updates; if we restrict the permission, then updates will likely require manual elevation in more scenarios.

Comment 14

[Robin Steuber (they/them) [:bytesized]]

(In reply to Adam Gashlin (he/him) [:agashlin] from comment #13)

if we restrict the permission, then updates will likely require manual elevation in more scenarios.

You can install to locations like C:\Firefox without elevation though. So there is no guarantee that manual elevation is possible for the user.

Comment 15

[ecbftw]

What user does the Mozilla Maintenance Service run as? I would imagine you can simply add that user in the permissions list when securing the directory's permissions, but I'm not familiar with how the update service works.

There are many cases where Windows machines are used in multi-user deployments (e.g. older citrix-style deployments and more modern equivalents). In other cases, simply installing Firefox on a Windows server (under say, D:\Program Files) would provide opportunities for attack, since multiple admins are likely to use the same server.

The way adversaries often operate in modern attacks is that they gain a foothold, then try to figure out which domain users have increased access (easy to do, because Active Directory will tell you all about it). Then they target those users by trying to gain access to the systems they use on a day-to-day basis. This is what pentesters sometimes refer to as lateral movement. This type of vulnerability would be used in the second stage to gain access to a more privileged domain account, for instance. I admit, it may not be that common for users to install outside of the default path, but if you did, you're 100% vulnerable!

Comment 16

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

(In reply to ecbftw from comment #15)

What user does the Mozilla Maintenance Service run as? I would imagine you can simply add that user in the permissions list when securing the directory's permissions, but I'm not familiar with how the update service works.

The maintenance service runs as SYSTEM, it is used to run the updater.exe with those high privileges so that updates can proceed without manual elevation. We restrict it to only work with installs in Program Files because an attacker-controlled installation directory can be used for privilege escalation up to SYSTEM, see bug 1643199.

Comment 17

[ecbftw]

To me, it sounds like the correct fix for that previous bug is really to fix the permissions of the installation directory up front, rather than limiting where the updater can run. Clearly the user could break their permissions later, but they could do that on Program Files too, and at that point it is not Firefox's fault.

Comment 18

[ecbftw]

Hi again. Any decision made on how to move forward?

I'd like to point out that DeepSurface has a 90 day disclosure policy. Details can be found here:
https://deepsurface.com/vulnerability-disclosure-policy/

Thanks.

Comment 19

[Nick Alexander :nalexander [he/him]]

Hi folks. Sorry for the delay -- busy busy.

Upon further discussion, we agree with the reporters that a local privilege escalation is possible here. However, this behaviour is, to our eyes, a feature and not a bug, since it enables home users to easily share an installation. That is, if you installed into a world-writeable directory (e.g., c:\Firefox), then you get a world-writeable (i.e., updatable by anybody) Firefox installation. That's a property that we want to preserve.

Since this may not be appropriate for enterprise users, we intend to clearly document this behaviour. We intend to update SUMO and the Security Technical Implementation Guides maintained by the US Department of Defense to be clear that multi-user installations should install to c:\Program Files (required to leverage the maintenance service) or to a directory which will not inherit world-writeable permissions. Enterprise installations to network drives likely already meet that criteria.

I'll leave our security team to toggle flags on this ticket. NI to :dveditz to do so and/or to correct my statement if I've made an error. Thanks for your effort reporting issues to Firefox, it is sincerely appreciated.

Comment 20

[ecbftw]

Hi Nick. Thanks for the update.

As you might have guessed, we disagree with the approach here, but I doubt we're going to change your mind.

Could Mozilla please issue a CVE for this issue so the public can track it and enterprises can more easily identify and correct it on an ad hoc basis? Our company is also a CNA and can issue CVEs as well, but we'd prefer it come from Mozilla.

Thank you,
tim

Comment 21

[ecbftw]

Can I get a update on my previous question?

Thanks,
tim

Comment 22

[Daniel Veditz [:dveditz]]

Although we understand how this could lead to problems if someone is not careful when they choose a non-default location for their install, it can also lead to the desired result on a locally-shared non-enterprise machine. Our understanding is that a CVE needs to be for a "vulnerability". We don't see this that way, and don't think CVEs were meant to cover pointy edges to be careful of.

mkaply: we should make sure this is mentioned in the enterprise documentation if it isn't, and probably the STIG ("make sure to install in the default c:\program files\ location"). needinfo? because I don't know if you track those changes as bugs, GH issues, or spreadsheet or whatever

Comment 23

[ecbftw]

So it is confirmed as a local privilege escalation issue, but it isn't considered a vulnerability? I'm not sure I understand.

We'll be looking to issue our own CVE in that case.

tim

Comment 24

[Daniel Veditz [:dveditz]]

We consider this a configuration error on the part of the installer, if this is not the behavior the person installing it wanted. But in many cases, maybe even most non-enterprise cases) this is the behavior that will keep the users of a shared family machine safest.

Enterprise users should install to the location that our maintenance service supports

Comment 25

[Mike Kaply [:mkaply]]

I'll have to manually update the STIG.

Looking at SUMO, this article is probably a good place to put a statement:

https://support.mozilla.org/en-US/kb/best-practices-installing-and-updating-firefox

Anything we have that's end user friendly for docs on this?

Comment 26

[:Gijs (he/him)]

(In reply to Mike Kaply [:mkaply] from comment #25)

I'll have to manually update the STIG.

Looking at SUMO, this article is probably a good place to put a statement:

https://support.mozilla.org/en-US/kb/best-practices-installing-and-updating-firefox

Anything we have that's end user friendly for docs on this?

I'm not sure who this question was directed to but it probably got lost. If you mean on SUMO, Fabi (flopez) is probably a good person to ping. If you mean in general, I would needinfo someone from the desktop integration team. Either way, let's make sure this does actually happen...

Comment 27

[Daniel Veditz [:dveditz]]

DeepSurface published their advisory Tuesday: https://deepsurface.com/deepsurface-security-advisory-lpe-in-firefox-on-windows/

Comment 28

[Mike Kaply [:mkaply]]

What do folks think of this wording? I'll add it to the page.

=Installation Directory=
For the best security, Firefox should be installed in the default directory on Windows, either Program Files or Program Files (x86). When installed in other directories, it's possible for the install to be updated by other users on the machine.

Comment 29

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

I'd avoid "updated", since installing in Program Files in particular lets you take advantage of the maintenance service, and updating isn't the concern. Proposed, maybe too detailed:

For the best security, Firefox should be installed in the default directory on Windows, either Program Files or Programs Files (x86). Firefox inherits the permissions of the install directory, and other directories may allow the install to be modified by other users on the machine.

Comment 30

[Mike Kaply [:mkaply]]

Page updated and information setup to go in STIG.