REQ: Make SBIE Compatible with Shadow Stack

[rugabunda]

Is this possible?

Process '\Device\HarddiskVolume7\Program Files\Mozilla Firefox\firefox.exe' (PID 12996) has encountered a shadow stack return address mismatch. The process will be allowed to continue execution because: the process is running in compatibility mode, and the mismatch occurred in a module that is not compatible with shadow stacks.
Process shadow stack strict mode: false
Appcompat options: 0x0

Return instruction executed from module '\Device\HarddiskVolume7\Program Files\Sandboxie-Plus\SbieDll.dll'.
(Instruction address: 0x746e2e84, module offset: 0x2e84, module compatible with shadow stacks: false)

Attempting to return to module '\Device\HarddiskVolume7\Program Files\Mozilla Firefox\firefox.exe'.
(Instruction address: 0x7ff7d6b1c8a0, module offset: 0x2c8a0, module compatible with shadow stacks: true)

Describe the solution you'd like

I'd like to see one of windows & CPU latest hardware security features, "shadow stack" not broken when using sbie., rop gagets are a common attack vector in browsers, which shadow stacks prevents.

[DavidXanatos]

could you please point me to the exact log location (system, security, application, some ware else) where you found this, I'll look into it.

[isaak654]

could you please point me to the exact log location (system, security, application, some ware else) where you found this, I'll look into it.

Open Event Viewer and expand: Applications and Services Logs/Microsoft/Windows/Security-Mitigations/Kernel Mode

[DavidXanatos]

I have investigated the issue and it was caused by how sandboxie used to hook the application entry point, I have re engineered the mechanism for x64 and it seams to solve the CET incompatibility, enabling shadow stacks support in the linker for SbieDll.dll now seams to work fine.

As this is a potentially breaking change it will be only included in the next large pre release build 1.7.0 as it needs to be thoroughly tested to see if the changed mechanism still works in all scenarios.

[rugabunda]

I have investigated the issue and it was caused by how sandboxie used to hook the application entry point, I have re engineered the mechanism for x64 and it seams to solve the CET incompatibility, enabling shadow stacks support in the linker for SbieDll.dll now seams to work fine.

As this is a potentially breaking change it will be only included in the next large pre release build 1.7.0 as it needs to be thoroughly tested to see if the changed mechanism still works in all scenarios.

Great work, thank you. Looking forward to testing.

[DavidXanatos]

1.7.0 is released, please test it thoroughly and report back if everything works as expected

[rugabunda]

Using System Informer (formerly process hacker) to list exploit mitigations for processes both inside and outside sandboxie... I will add the discrepancies. You will note sandboxie prevents flow control guard, extension points protections, (for better or worse?) and subsets of ASLR, namely "high entropy, force relocate, disallow stripped images".

Telegram now works with shadowstacks enabled, with default, and enforce mode.

Telegram In Sandboxie:

ASLR (minimum)
DEP
Dynamic code (downgrade)
Images restricted (remote images, low mandatory label images)
Indirect branch prediction
Non-System fonts disabled
Payload Restrictions
Spectulative store bypass
Strict handle checks
Strict Stack Protection (shadows stacks, enforced mode)

Outside Sandboxie:

*ASLR (high entropy, force relocate, disallow stripped)
DEP
*CF Guard [Control flow guard (CFG)]
Dynamic code (downgrade)
*Extension points disabled
Images restricted (remote images, low mandatory label images)
Indirect branch prediction
Non-System fonts disabled
Payload Restrictions
Spectulative store bypass
Strict handle checks
Strict Stack Protection (shadows stacks, enforced mode)

This is just for information purposes, and to show the commonalities with the above... it appears vivaldi is not compatible with shadow stacks with or without sandboxie.

Vivaldi With Sandboxie:

ASLR (minimum)
DEP
Dynamic code (downgrade)
Images restricted (remote images, low mandatory label images)
Indirect branch prediction
Non-System fonts disabled
Signatures restricted (microsoft only)
SMT-thread branch target isolation
Spectulative store bypass
Strict handle checks
Win32k system calls disabled (enforced by vivaldi itself)

You will note sandboxie prevents vivaldi from enforcing its own exploit protections, namely Child Processes.

Without Sandboxie:

*ASLR (high entropy, force relocate, disallow stripped)
DEP
*CF Guard [Control flow guard (CFG)]
*Child process creation disabled (enforced by vivaldi itself)
Dynamic code (downgrade)
*Extension points disabled
Images restricted (remote images, low mandatory label images)
Indirect branch prediction
Non-System fonts disabled
Signatures restricted (microsoft only)
SMT-thread branch target isolation
Spectulative store bypass
Strict handle checks
Win32k system calls disabled (enforced by vivaldi itself)

I will share more information as I continue to experiment.

[rugabunda]

@DavidXanatos This is a must read article on exploit protection security of browsers https://madaidans-insecurities.github.io/firefox-chromium.html

Firefox crashes with shadow stacks set to "Enforce for all modules instead of only compatible modules", both inside and outside sandboxie. This is on a fresh install with no addons/extensions. Firefox works with shadowstacks without enforce mode, both in and outside of sandboxie.

In Firefox 109.0 The Arbitrary Code Guard exploit protection has been enabled in the media playback utility processes, improving security for Windows users. https://www.mozilla.org/en-US/firefox/109.0/releasenotes/

For some reason, firefox uses restricted images only inside sandboxie

Firefox Portable In Sandboxie:

ASLR (minimum)
DEP (permanent)
Dynamic code (downgrade)
*Images restricted (remote images, low mandatory label images)
Indirect branch prediction
Non-System fonts disabled
Payload Restrictions
Spectulative store bypass
Stack Protection (shadow stacks, non forced mode)
Strict handle checks

Firefox Portable Outside Sandboxie:

*ASLR (high entropy, force relocate, disallow stripped)
*CF Guard [Control flow guard (CFG)]
DEP (permanent)
Dynamic code (downgrade)
*Extension points disabled
Indirect branch prediction
Non-System fonts disabled
Payload Restrictions
Prefer system32 images
Spectulative store bypass
Strict Stack Protection (shadows stacks, non forced mode)
Strict handle checks

[rugabunda]

1.7.0 is released, please test it thoroughly and report back if everything works as expected

could you please point me to the exact log location (system, security, application, some ware else) where you found this, I'll look into it.

Open Event Viewer and expand: Applications and Services Logs/Microsoft/Windows/Security-Mitigations/Kernel Mode

Seems to be working fine without any errors, can this be closed? thank you