Block access to sandboxed process memory

[bastik-1001]

Is your feature request related to a problem or use case?

Sandboxie used to allow sandboxed processes to read memory of other processes, which got changed so that processes can't do that any longer, by default.

Due to the driver being in control of what runs under Sandboxie's supervision this is something that can be done. Is it possible to prevent processes running outside Sandboxie (on the host) from reading the memory of processes in some sandbox?

The rational is the same as with sandboxed processes not being able to pull secrets from the host processes memory, just flipped around. Host processes not being able to pull secrets from processes running inside Sandboxie.

Describe the solution you'd like

Sandboxie providing a mechanism that protects a sandboxed processes memory from host processes.

This might be done by using the hooks the driver provides or it might be possible to also create an encrypted memory space (in RAM), where only the sandbox has access to. (No other sandbox nor the host.) Maybe modern hardware can aid such an attempt to encrypt individual sandboxes' memory.

Describe alternatives you've considered

I understand if that is not within the scope of Sandboxie, although that is some form of isolation.

[DavidXanatos]

Memory encryption is not possible without being a feature of the OS kernel itself.

But we can protect any process, using the obCallback mechanism and prevent other processes from being able to open handles to them hence blocking memory reading.

So what we would want to create would be a protected box to keep secrets in.
Such a box would have to have characteristics of a Compartment type box as to not reduce any other protection processes may normally have.

What would be the use cases or such a box type?

[bastik-1001]

Memory encryption is not possible without being a feature of the OS kernel itself.

Well, that's out of the picture, then.

What would be the use cases or such a box type?

Online banking, for the most part, but also for online services that get access to medical information and potentially private information that is used for authentication/authorization, like a social security number.

Of course the system itself is supposed to be trusted, but limiting the trust that is needed can be good. I don't think people would be careless, installing Sandboxie is something only people that are considering it being beneficial for them, after all.

I'm not sure if it will help with #2117, but having memory being inaccessible seems to be a trade-off between data protection and anti malware software. The later might even be allowed by some configuration option, for processes being able to access that memory.

[DavidXanatos]

I like the idea, generally windows suxxx big times with regard to operational security, basically if you run some malware it can read your keepass's memory and run away with all your passwords, no UAC or admin rights required.

Being able to create somewhat protected compartments sounds mighty useful, although obCallbacks would not be enough we also need to monitor image loads to prevent unwanted dll's to be loaded into our protected processes, and perhaps some additional things to.

[bastik-1001]

Password managers/vaults are another use case, indeed.

monitor image loads to prevent unwanted dll's to be loaded into our protected processes, and perhaps some additional things to.

Having the memory being protected could be a starting point, but, of course, it is not complete. So you are right.

[diversenok]

obCallbacks and similar driver-based features that affect unsandboxed processes seem like an overkill and a bad idea. Especially if they can affect unsandboxed admins in an attempt to protect low-privileged sandboxed applications. I can tell from experience of breaking AV/EDR software that vendors who tried to implement custom driver-based protection for their products often introduce vulnerabilities that allow abusing this infrastructure.

I agree that it might be useful to protect sandboxed applications from unsandboxed non-admin processes, but using the built-in security mechanisms instead. Windows already includes a security boundary between normal user accounts that isolates them from each other. I'm pretty sure David can merely adjust the default DACL for sandboxed processes to prevent access from unsandboxed programs and call it a day.

Otherwise, there are some caveats that complicate the task of making it more bulletproof:

• Sandboxie runs sandboxed programs under the same user as the owner of the interactive session (not in terms of what the process token shows, but rather what it uses for access checks and considers HKCU and the profile directory). It exposes an attack surface that even the driver will have hard time mitigating. Sharing the user is also what prevents UAC (even in the always-notify mode) from being a security boundary, so don't expect Sandboxie to fix it.
• Sharing the desktop means we need to rely on UIPI, which uses a uni-directional trust model based on integrity levels. UI-based attacks originating from unsandboxed programs are something you cannot fully protect sandboxed processes from, whether using the driver or not. These include injecting input, capturing screenshots, and intercepting clipboard. The only reliable (but a bit inconvenient) solution against these attacks is to run programs on a different desktop.

[bastik-1001]

obCallbacks and similar driver-based features that affect unsandboxed processes seem like an overkill and a bad idea. Especially if they can affect unsandboxed admins in an attempt to protect low-privileged sandboxed applications. I can tell from experience of breaking AV/EDR software that vendors who tried to implement custom driver-based protection for their products often introduce vulnerabilities that allow abusing this infrastructure.

I trust that expertise of yours and the least thing I want is for Sandboxie to get a security issue, it did not have before or making one worse.

[DavidXanatos]

Well I was thinking of this feature more like an extension of the compartment type boxes, so no restricted token, or alike. Just registry and file system filtering + ob callback protection on top.

[DavidXanatos]

In build 1.3.3 there will be an option to block selected host processes from accessing boxed programs, this feature will be however intended as a compatibility measure and not as a security feature, it allows to create compatibility with ReHips: https://www.wilderssecurity.com/threads/rehips-sandboxie-incompatibility-affecting-google-chrome-and-other-apps.447282/