SandBoxIE to harden SRP (software restriction policy)?

[catBot]

Dear Tzur!
Thank you for your great utility!

For quite some time I believed that (among other measures) the Software Restriction Policies would be a serious barrier against an exploit. (I'm talking about the "disallowed by default" SRP settings)

To my horrorzz MS has sabotaged its implementation of SRP - a series of posts by Didier Stevens proves that bypassing SRP is rather easy.

It involves (among other things) the SANDBOX_INERT flag in the CreateRestrictedToken function, the SAFER_TOKEN_MAKE_INERT flag in the SaferComputeTokenFromLevel function, the LOAD_IGNORE_CODE_AUTHZ_LEVEL argument to the LoadLibraryEx call.

My question is:

• is SandBoxIE able to disable or remove those flags and arguments, replace the LoadLibraryEx call with the SRP-compliant LoadLibrary one?

My goal is to restore the protecting power of the "disallowed by default" SRP as a proper preventive measure.

Thank you in advance!

[Curt@invincea]

The goal of Sbie is not to restrict, but to contain. These SRP settings were added by MS and fully documented. I expect they had a reason to add these (e.g. a lot of applications won't work without them).

[catBot]

As I understand those MS's descriptions - SRP bypass is there only for software installers, not for everyday use.

And since sandboxing a particular program is already a deviation from what MS has expected - adding the SRP/Applocker-hardening feature would be greatly beneficial security-wise. If someone does not need them - these hardening features could be optional - just like the current "Drop rights" check-box.

I kindly ask you to consider adding SRP/Applocker-hardening to SandBoxIE:

1. it will apply only to sandboxed program(s) (will not interfere with normal installation procedure to the outside of a sandbox)
2. as an additional protection layer it will improve security (not only an exploit would be contained but also made nearly impossible)
3. the SandBoxIE is the only place where this SRP/Applockler-hardening could be implemented cleanly

I hope other SandBoxIE users could join the discussion regarding this topic.

Thank you in advance!

[catBot]

Please excuse my insistence, but I find this topic very serious.

Curt says SandBoxIE's goal is to contain - indeed, containing things is good.
May I ask - why do we want to contain things from spreading into our OSes?

As I see it - the answer is: for security reasons.

The additional features I ask for are intended to lessen the harm that a sandboxied program could inflict even within its' sandbox.
Any harm-preventing measures are welcome in a multi-layered security approach.

Please comment.
Thank you in advance.

[deugniet]

Like Simple Software-restriction Policy?

http://sourceforge.net/projects/softwarepolicy/

[Mr.X]

@catBot
Want a layered security? Look at the combo in my signature, and in here you will find everything about it: http://www.wilderssecurity.com/threads/ ... st-2298875

[catBot]

Thanks for the suggestion but I want to use as little of 3rd-party software as possible. If an OS has its' built-in policies - I'd prefer to use them instead to some external code.

My multi-layered approach consists of the following:

1. a non-administrative account for everyday jobs;
2. the "disallowed by default" SRP setting; (only the administrator-preapproved/preinstalled programs are allowed to run by a user, no code from user-writable areas is runnable)
3. all available OS-hardening measures are enabled (DEP == "always ON", ASLR, etc)
4. users are prevented from installing printer drivers;
5. unsigned drivers are not installable even by an administrator;
6. if I were on vista or above - I'd disable UAC; (there should be no way for a mortal user to mess with OS's settings, any code requiring administrative rights should silently fail)
7. the Enhanced Write Filter is used to protect the system disk from all unwanted alterations; (after a reboot OS returns to a known-to-be-clean state)
8. all security fixes and patches are installed;
9. all non-essential system services are turned off; (like remote registry edit, DNS cache, etc);
10. auto-run is disabled on all drives;
11. all internet-facing programs are run SandBoxIEd.

So far this works for me since ~2002 when I've moved to winXP-SP1.

Until I've read Didier Stevens' articles I thought I was [s]completely[/s]reasonably safe.
As I've said, I was horror-ed to learn that SRP is trivial to bypass.

I ask SandBoxIE developers to have a look if masking off/disabling those flags/parameters of the certain system calls could be implemented in the SandBoxIE - the only clean and easy place to properly enforce the SRP discipline, since all the potentially-vulnerable/exploitable programs are running SandBoxIEd.

I'd like to accept no compromises security-wise if technically possible.

Thank you in advance.

[catBot]

I attempted to contact Tzur with PM, but seems he left the forum - last visit was 2014-January.

Are there other ways to contact the development team to have their comments on the topic?

[catBot]

I've PMed Tzur two weeks ago - PM is not delivered yet...

Is Tzur still in this business?

[Curt@invincea]

See this thread http://forums.sandboxie.com/phpBB3/view ... 17&t=17514

[Curt@invincea]

To respond to your original point, I don't think this is something we want to add to Sandboxie. The design of Sandboxie is to allow applications in the sandbox to run freely, but to contain them within the sandbox. Adding restrictions will just cause more compatibility issues.

[catBot]

To respond to your original point, I don't think this is something we want to add to Sandboxie. The design of Sandboxie is to allow applications in the sandbox to run freely, but to contain them within the sandbox. Adding restrictions will just cause more compatibility issues.

Dear Curt,

I kindly ask you to reconsider this again.

Hardening the Applocker/SRP by means of SandBoxIE's handling of said flags and parameters is perfectly in-line with the already existing SandBoxIE's measures like the "Drop Rights" and all the features managing the inter-process communications (Resource Access->IPC/Window/COM). Just like those measures - this could be also optional.

I strongly believe that applying those SRP-hardening measures would provide more robustness to SandBoxIE's containment capabilities.

It is clearly stated in MS's documentation that the only valid reason for Applocker/SRP bypass is the software installation process. No compatibility issues would arise from it for running the already installed programs under SandBoxIE - I'm talking about the non-malevolent/exploit sort of programs.
Any "compatibility issue" would therefore constitute a successful exploit prevention.

In my scenario I install the software I use to the outside of a sandbox, I almost never install things within a sandbox.
My scenario is about further hardening the every-day usage security of the already installed software running under the SandBoxIE's supervision, as an additional defense measure against any 0-day threat.


Please have a look into this again.

Thank you in advance.

[JoeHood]

Have you looked at the Restrictions tab in Sandboxie Control? You can limit which programs can access the internet and limit what programs can even run at all.

[catBot]

Have you looked at the Restrictions tab in Sandboxie Control?

Thank you for the advise.

I do not have any programs that I do not want to run - only the pre-approved programs are there to be used by a non-administrative user.
Therefore I have nothing to include in the Restrictions tab.

My goal is to combine the strengths of SRP/Applocker with SandBoxIE to prevent attacker's ability to bring in his own code and run it.
As of now it is possible to make a browser to download an attack tool to a user-writable folder and to make it (this same tool) to run - because it is possible to circumvent SRP/Applocker rules.
This is exactly what I want to stop.

[JoeHood]

Therefore I have nothing to include in the Restrictions tab.

It works the opposite - whitelisting. You include only those preapproved programs.