Will Sandboxie's isolation be easily bypassed by thread pool injection?

https://github.com/sandboxie-plus/Sandboxie/discussions/4269
This was a discussion at the end of September last year. The original discussion thread said "the level 1 reporter of this vulnerability is not willing to disclose the original sample, so there is no POC", but because there was no follow-up discussion, I don't know whether it is true or not.
I hope someone who has knowledge about this can tell me, is it really possible to bypass the sandbox so easily? So if SyscallLockDown=y is not set, will Windows just let it go without any checking mechanism? If this is true, I think it will not only affect Sandboxie, but many other sandbox programs will become vulnerable.

 

So should I understand that the SyscallLockDown=y option is not enabled even in red boxes?
Where in the GUI this setting is found?

 

To me it's also not clear if Sandboxie can be bypassed or not, regardless of the SyscallLockDown setting. I've read that if you don't alllow admin rights in the sandbox, the exploit is stopped.

Plus, Sandboxie doesn't allow sandboxed processes to open unsandboxed processes. But the topic starter keeps claiming that this POC uses a syscall that is not monitored by Sandboxie? It's very confusing, perhaps David Xanatos can respond to this topic.

 

@DavidXanatos
Should I understand that the SyscallLockDown=y option is not enabled even in red boxes?
Where in the GUI this setting is found?

 

Thank you @bjm_

Didn't know these lines were there internally, I had them explicitly in my ini file (very old config), so I think it's safe to delete them from each box.

 

@Mr.X Yeah...I don't know changes (if any) since that info was published.
And I run Security Hardened for my browser sbox's.

 

The reporter did not disclose any instructions how to reproduce the claimed issue.

The OP is not the source of the informations so its a bit of a "telephone game"/"silent mail" someone tells something to someone and that one repeats it to someone else and so on. So there were inconsistent and contradictory information offered.
There was no indication of an actual sandboxie issue, rather a windows bug that Sandboxie fails to mitigate.
That said, if y unprivileged process on windows can use a harmless system call to inject code into lsass.exe that's a major windows bug and big problem for MSFT to fix.


Sandboxie filters all relevant syscalls always (except in green/cyan boxes). In red boxes UseSecurityMode=y the option SysCallLockDown=y is always enforced.
But as said if a system call to some "harmless" kernel API, perhaps even if executed with a unprivileged token, allows to execute code in the kernel because of a bug in windows itself than its for MS to fix.

If the reporter would disclose the details of the exploit Sandboxie could, depending on the details of the exploit, implement a targeted temporary mitigation measure until MSFT fixes the underlying windows vulnerability.
That said if the vulnerability allows Kernel code execution even with a unprivileged anonymous token then there is nothing Sandboxie could reliably do to mitigate that.

PS: if such threads with urgent questions pop up please PM me to get a same day answer.