1466618 - Firefox 58 up to at least 60.0.1 is not loading any pages when running with low integrity level in Windows

Status: RESOLVED INVALID

(Core :: Security: Process Sandboxing, defect)

Description

[binami]

Attachment: complete_command.bat

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
Build ID: 20180516032328

Steps to reproduce:

 - Make Firefox more secure against malware trying to escape from the browser with a little known yet effective trick using a build-in Windows command line tool: "icacls firefox.exe /setintegritylevel low" (you also have to modify some folder integrity levels, complete command see attached file)
 - Open Firefox
 - Navigate to any page (e.g https://mozilla.com or about:config)



Actual results:

 - Page does not load, only showing white background.



Expected results:

 - Pages loads and displays.


Some additional notes:

This is very related to https://bugzilla.mozilla.org/show_bug.cgi?id=1433065 but I was asked to open a new bug for this. My symptoms are the same, I can also solve the problem by "set MOZ_DISABLE_CONTENT_SANDBOX=1", but the issue is triggered by something different in my case. (that's why I was probably asked to open a new bug)

This trick I use here is actually nothing totally unusual. It was sometimes advertised by professional IT websites to do this, e.g. https://www.heise.de/security/artikel/Firefox-tiefergelegt-271520.html
So this is definitively something you should be concerned about.

And I know that Firefox nowadays tried to implement its own sandboxing, but then only some subprocesses are sandboxed and a potential malware could still exploit a vulnerability in the communication channel with these subprocesses whereas with this technique you can put the whole Firefox process into low integrity mode which is superior.

Comment 1

[binami]

More notes:

This always worked for pre-Quantum Firefox version (e.g. 52 ESR) and the issue first occurred to me after I switched to Quantum (i.e. 60).

Contrariety to https://bugzilla.mozilla.org/show_bug.cgi?id=1433065 the issue still exists in the most recent version of Firefox (60.0.1) for me, so it seems to be only fixed for one particular case discussed in the other bug (where it was caused by antivirus protection), but seemingly not for other cases (like Windows low integrity mode I am reporting here).

Comment 2

[Bob Owen (:bobowen)]

(In reply to binami from comment #0)

Thanks for taking the time to file the separate bug, but I'm going to mark this as invalid.

The problem with this approach is that while in theory you increase the security of the firefox.exe processes, because you have to set other folders to low integrity, you are actually reducing the overall security of your whole system.
Any other low integrity processes that get compromised, can potentially write to those folders.

So, the approach we (and all other major browsers) take is to run child processes that have as few privileges as possible and do as much processing as we can in those, particularly when processing untrusted information.
If they do get compromised the damage is hopefully limited.

I say "in theory" above, because in reality running a process at low integrity is not enough to protect your system from it, if it gets compromised.
It still allows most files to be read and network connections, also escalating the privileges through other means is probably not too difficult.
In order to prevent these means removing more privileges, but you need at least one process with higher privileges in order to function as a browser.
That's not to say there aren't privileges that we can remove from the parent firefox.exe process, we are actively looking into that, it's just that as it stands running at low instead of the medium integrity isn't one of them.

As you say, this higher privileged process is an attack vector for privilege escalation, but that's just something of which we have to be mindful. To a certain extent all other higher privileged processes are also a target.

One of the privileges we recently removed from the content processes was to be able to load low integrity images (DLLs and EXEs), so that is probably what prevents this technique from working at all.
The symptoms you see are what happens when the content process won't start, which is why it looked similar to bug 1433065, even though the root cause is different.