Developing a Sandbox for Windows

All off-topic discussion goes here.
Post Reply
Victor43
Posts: 60
Joined: Thu Dec 15, 2011 7:34 am
Location: Canada

Developing a Sandbox for Windows

Post by Victor43 » Sun Jan 07, 2018 6:53 am

Two questions to ask. 1. Does WFP have a Registry Callback which allows all registry calls at user and kernel level to be filtered and 2. How to intercept a thread from creating a thread or process ?

User avatar
Vrtule
Posts: 455
Joined: Sat Mar 13, 2010 9:14 pm
Location: Czech Republic
Contact:

Re: Developing a Sandbox for Windows

Post by Vrtule » Sun Jan 07, 2018 11:56 am

Hello,
How to intercept a thread from creating a thread or process?
The PsSetCreateProcessNotifyRoutineEx should work for blocking process creation (AFAIR you get also the information about the thread creating the new process since the callback is run in its context). As far as I know there is nothing similar for blocking thread creation. However, if you need to block creation of remote threads, that usually requires obtaining a handle to the target process with write permissions (and that can be observer/blocked via ObRegisterCallbacks).

Registry operations can be monitored and filtered through CmRegisterCallback(Ex). Well, some operations are kinda undocumented, so it is not easy to filter them, howerver, such usually require administrative privileges (saving/loading/replacing/restoring registry trees).

Victor43
Posts: 60
Joined: Thu Dec 15, 2011 7:34 am
Location: Canada

Re: Developing a Sandbox for Windows

Post by Victor43 » Sun Jan 07, 2018 11:01 pm

@Vrtule thank you. Can you tell me one thing where can these special functions be placed ? Would they require to be placed inside a separate driver file just designed for the sandbox or could they be placed inside a WFP driver file (driver file designed to filter TCP traffic) ? I'm interested in sandboxing the web-browser and POP/SMTP applications.

User avatar
Vrtule
Posts: 455
Joined: Sat Mar 13, 2010 9:14 pm
Location: Czech Republic
Contact:

Re: Developing a Sandbox for Windows

Post by Vrtule » Mon Jan 08, 2018 12:27 pm

When I was playing with HIPS/sandboxing, I had a driver implementing the main logic and separate drivers covering individual areas (file system, registry, network, process/thread access...). These drivers were connected to the main one as plugins. The whole thing worked quite nicely. I have the source code somewhere and I will probably release it to the public in the future (well, it is quite old and I seem not to have time to continue with it).

However, AFAIK there is nothing preventing you from monitoring/filtering registry and network in one driver. Although, I expect Microsoft is probably encouraging people to write separate drivers for separate things.

So, you may try the one-driver-rules-them-all approach and it should work.

Victor43
Posts: 60
Joined: Thu Dec 15, 2011 7:34 am
Location: Canada

Re: Developing a Sandbox for Windows

Post by Victor43 » Mon Jan 08, 2018 11:36 pm

@Vrtule thank you. Since you had an opportunity to work with a sandbox can you tell me if a sandbox is done right what are the chances of exploits passing through the sandbox and able to make unauthorized changes to the system ? Second question what do you know of cloud based sandboxing ?

User avatar
Vrtule
Posts: 455
Joined: Sat Mar 13, 2010 9:14 pm
Location: Czech Republic
Contact:

Re: Developing a Sandbox for Windows

Post by Vrtule » Tue Jan 09, 2018 12:00 pm

Second question what do you know of cloud based sandboxing ?
Nothing actually.
Since you had an opportunity to work with a sandbox can you tell me if a sandbox is done right what are the chances of exploits passing through the sandbox and able to make unauthorized changes to the system?
You should really know the interfaces you are using. Although they might look really nicely in the documentation but they implementation might have certain drawbacks. For example, on Windows 7 and older, when filtering certain types of registry operations (e.g. registry value deletion), some data are not copied to kernel buffers by the operating system (e.g. the value name), so the sandoxed application can change tem at any time and there is a high chanse of a TOCTOU vulnerability.

The best way (on my opinion) is to run the sandoxed application with least privileges possible (zero integrity level, under a heavily constrained job object etc.) and hook its userland libraries. Your hooks will communicate with the sandbox which decides what actions can or cannot be permitted. The point is that if the application bypasses your hooks (e.g. by invoking system calls directly) it cannot do much harm.

I think that the kernel registry callbacks are useful when you need to protect several registry keys/values (or areas), or to restrict the sandoxed application from previous paragraph from its privileges even more. But using them as the main way of implementing the sandbox is not a good idea.

Victor43
Posts: 60
Joined: Thu Dec 15, 2011 7:34 am
Location: Canada

Re: Developing a Sandbox for Windows

Post by Victor43 » Wed Jan 10, 2018 11:54 pm

You should really know the interfaces you are using. Although they might look really nicely in the documentation but they implementation might have certain drawbacks. For example, on Windows 7 and older, when filtering certain types of registry operations (e.g. registry value deletion), some data are not copied to kernel buffers by the operating system (e.g. the value name), so the sandoxed application can change tem at any time and there is a high chanse of a TOCTOU vulnerability.

The best way (on my opinion) is to run the sandoxed application with least privileges possible (zero integrity level, under a heavily constrained job object etc.) and hook its userland libraries. Your hooks will communicate with the sandbox which decides what actions can or cannot be permitted. The point is that if the application bypasses your hooks (e.g. by invoking system calls directly) it cannot do much harm.

I think that the kernel registry callbacks are useful when you need to protect several registry keys/values (or areas), or to restrict the sandoxed application from previous paragraph from its privileges even more. But using them as the main way of implementing the sandbox is not a good idea.
I think I understand what you're saying overall but can you elaborate a little on what you mean "interfaces" ? Also you mentioned hooking userland libraries how can this be done best ? More importantly if the application by-passes the hooks as you mentioned by calling the system functions directly then what is the point of implementing userland hooks ? With respect to adding a registry callback I'm mostly interested in preventing any changes to the registry so only write capabilities however file operations, blocking process creation along with write protecting registry changes altogether shall be used to devise least privileges. Not sure what you meant by "under a heavily constrained job object" ? Could you elaborate a little here.

Thanks again

User avatar
Vrtule
Posts: 455
Joined: Sat Mar 13, 2010 9:14 pm
Location: Czech Republic
Contact:

Re: Developing a Sandbox for Windows

Post by Vrtule » Fri Jan 12, 2018 3:36 pm

can you elaborate a little on what you mean "interfaces"
In this context, interface is a set of APIs used for certain purpose (e.g. filtering registry calls).
Also you mentioned hooking userland libraries how can this be done best ?
Well, probably inline hooks will do.
More importantly if the application by-passes the hooks as you mentioned by calling the system functions directly then what is the point of implementing userland hooks ?
The key point here is that the sandboxed application itself has as less privileges as possible when talking about the Windows security model. However, there may be "permissions", you wish to grant the application, that cannot be easily expressed by the terms of the security model. As an examle, let's say you need to grant the sandboxed application access only to a file A (and just image you cannot do that via the standard security means, such as ACLs). From the security model viewpoint, the application does not have access to A, however, your userland hooks may be used to communicate with your more privileged application that can then access A on behalf of the sandboxed one.

So, the userland hooks are used to grant the sandboxed application some extra permissions, not to restrict it. The assumption is that a nice application will not bypass the hooks, so it will get permissions it needs. However, the malicious application that bypasses the hooks gets nothing, since the sandbox restricts it by the security model (low integrity level, restricting SIDs in the access token etc.).
heavily constrained job object
Job objects allow you to place some retrictions on applications run under them. At the time I was researching them, the most interesting was the GUI restriction – e.g. preventing the sandobxed application from sending Windows messages outside the job object. With new versions of Windows, the possible set of restrictions grew quite a bit. I just wanted to point you to job objects as an interesting contept for implementing a sandbox.

Victor43
Posts: 60
Joined: Thu Dec 15, 2011 7:34 am
Location: Canada

Re: Developing a Sandbox for Windows

Post by Victor43 » Tue Jan 16, 2018 3:35 am

@Vrtule thank you for follow-up. It's very much appreciated.

Victor43
Posts: 60
Joined: Thu Dec 15, 2011 7:34 am
Location: Canada

Re: Developing a Sandbox for Windows

Post by Victor43 » Thu Jan 25, 2018 5:34 am

I have another question about Sandbox design. Other than the avenues of interception of untrusted code what else is there involved in the overall design of a sandbox ?

Post Reply