Sandboxie causing Firefox Nightly crashes

[bobowen]

Describe what you noticed and did

We have recently made changes to further restrict the SIDs in the access tokens for the content processes on Firefox Nightly.
We have been getting crashes since this change and many of them appear to have SbieDll.dll loaded in the process.

The crash is occurring when we fail to initialize COM security here.
This is before we lower the token on the main thread, so there shouldn't be any change from a permission point of view at this point.

This is our bug for reference: Bug 1895174

How often did you encounter it so far?

No response

Expected behavior

Not crashing.

Affected program

Firefox Nightly 131.0a1

Download link

https://www.mozilla.org/en-US/firefox/all/#product-desktop-nightly

Where is the program located?

Not relevant to my request.

Did the program or any related process close unexpectedly?

Yes, it did, but I don't want to share the .dmp file(s) for privacy reasons.

Crash dump

No response

What version of Sandboxie are you running now?

5.69.6.0

Is it a new installation of Sandboxie?

I recently did a new clean installation.

Is it a regression from previous versions?

No response

In which sandbox type you have this problem?

Not relevant to my request.

Can you reproduce this problem on a new empty sandbox?

Not relevant to my request.

What is your Windows edition and version?

WIndows 10 and 11

In which Windows account you have this problem?

Not relevant to my request.

Please mention any installed security software

n/a

Did you previously enable some security policy settings outside Sandboxie?

No response

Trace log

No response

Sandboxie.ini configuration

No response

[bobowen]

It's not very clear to me what is going on here, because it seems to fail in different places (and I can't reproduce with a local build).
It appears that something is going wrong with the token on the main thread early on.
In our normal sandbox case the main thread is running with an impersonation token at first to give it access to load DLLs and to do other initialization.

[love-code-yeyixiao]

You should know that we never inject SbieDll.dll when a process running outside boxes.You didn't find "SbieDll.dll" in the log,right?

…

---Original--- From: "Bob ***@***.***> Date: Tue, Aug 27, 2024 22:51 PM To: ***@***.***>; Cc: ***@***.***>; Subject: [sandboxie-plus/Sandboxie] Sandboxie causing Firefox Nightly crashes(Issue #4183) Describe what you noticed and did We have recently made changes to further restrict the SIDs in the access tokens for the content processes on Firefox Nightly. We have been getting crashes since this change and many of them appear to have SbieDll.dll loaded in the process. The crash is occurring when we fail to initialize COM security here. This is before we lower the token on the main thread, so there shouldn't be any change from a permission point of view at this point. This is our bug for reference: Bug 1895174 How often did you encounter it so far? No response Expected behavior Not crashing. Affected program Firefox Nightly 131.0a1 Download link https://www.mozilla.org/en-US/firefox/all/#product-desktop-nightly Where is the program located? Not relevant to my request. Did the program or any related process close unexpectedly? Yes, it did, but I don't want to share the .dmp file(s) for privacy reasons. Crash dump No response What version of Sandboxie are you running now? 5.69.6.0 Is it a new installation of Sandboxie? I recently did a new clean installation. Is it a regression from previous versions? No response In which sandbox type you have this problem? Not relevant to my request. Can you reproduce this problem on a new empty sandbox? Not relevant to my request. What is your Windows edition and version? WIndows 10 and 11 In which Windows account you have this problem? Not relevant to my request. Please mention any installed security software n/a Did you previously enable some security policy settings outside Sandboxie? No response Trace log No response Sandboxie.ini configuration No response — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[bobowen]

You should know that we never inject SbieDll.dll when a process running outside boxes.You didn't find "SbieDll.dll" in the log,right?

This was noticed from crash reports where the SbieDll.dll was loaded in the crashing process.
So this must be people who are running Firefox within a sandboxie sandbox.

We can reproduce similar crashes by running the latest Nightly in the sandboxie DefaultBox.
Either by using the "Run" option or the "Force Programs" option.

[offhub]

For me it only crashes on startup when using the Application Compartment type sandbox with the following Firefox setting.

pref("security.sandbox.content.level", 8);

[bobowen]

For me it only crashes on startup when using the Application Compartment type sandbox with the following Firefox setting.

pref("security.sandbox.content.level", 8);

This is the setting that moves us to a USER_RESTRICTED access token level.

It is now not reproducing for me with the latest Nightly for the DefaultBox (it is for Application Compartment type as you say).
So, perhaps something else was also interacting with this.
I'll try and bisect recent changes.

[bobowen]

It seems that the crash in the DefaultBox required both using the USER_RESTRICTED access token level and a PGO build that had the firefox sandbox enabled during the PGO instrument and run phases. This second change was backed out for other reasons.
I've tried to reproduce with a local PGO build but to no avail.

The similar crash with only USER_RESTRICTED that happens with the Application Compartment type sandbox appears to be caused when the call to ProcessToken::GetProcessToken in CRpcResolver::GetConnection fails within the CoInitializeSecurity call in combase.dll.
I've looked at the process and thread tokens just after the failure and I don't see any obvious reason for this.
I've not dug any deeper because I had some trouble with breakpoints causing failures when debugging within the sandboxie sandbox.

[DavidXanatos]

which firefox build number is affected and is the issue still present?

I don't see any issues with 131.0b6

[bobowen]

which firefox build number is affected and is the issue still present?

It was originally reproduced in Nightly which was the only place that had the USER_RESTRICTED and PGO changes.
After the PGO changes were backed out, I could only reproduce with an Application Compartment type sandbox:
https://www.mozilla.org/en-US/firefox/all/#product-desktop-nightly