"Sandbox Roulette" - BlackHatEU2013 – Day2.

I found an article about Sandboxie.

"BlackHatEU2013 – Day2 – The Sandbox Roulette: Are you ready to ramble"
-http://blogbromium.files.wordpress.com/2013/03/blackhat-2013-sandbox-roulette_wp.pdf-

"What comes inside an application sandbox always stays inside the sandbox. Is it REALLY so? This talk is focused on the exploit vectors to evade commercially available sandboxes Las Vegas-style: We'll spin a "Sandbox Roulette" with various vulnerabilities on the Windows Operating System and then show how various application sandboxes hold up to each exploit. Each exploit will be described in detail and how it affected the sandbox.

There is a growing trend in enterprise security practices to decrease the attack surface of vulnerable endpoints through the use of application sandboxing. Many different sandbox environments have been introduced by vendors in the security industry, including OS vendors, and even application vendors. Lack of sandboxing standards has led to the introduction of a range of solutions without consistent capabilities or compatibility and with their own inherent limitations. Moreover some application sandboxes are used by malware analysts to analyze malware and this could impose risks if the sandbox was breached.

This talk will present an in-depth, security focused, technical analysis of the application sandboxing technologies available today. It will provide a comparison framework for different vendor technologies that is consistent, measurable, and understandable by both IT administrators and security specialists. In addition we will explore each of the major commercially available sandbox flavors, and evaluate their ability to protect enterprise data and the enterprise infrastructure as a whole. We will provide an architectural decomposition of sandboxing to highlight its advantages and limitations, and will interweave the discussion with examples of exploit vectors that are likely to be used by sophisticated malware to actively target sandboxes in the future..."

 

Maybe not but the pdf does mention Sandboxie specifically and notes it was tested and failed against CVE-2012-0217.

'We tested the exploit for the CVE-2012-0217 vulnerability (misleadingly named “User Mode Scheduler Memory Corruption” in Microsoft bulletin MS12-042) in the Sandboxie environment on the x86_64 platform running the default Windows 7 SP1 kernel. This vulnerability is caused by not sanitizing the return address of a system call; the non-canonical return address results in an unexpected exception being raised that is handled incorrectly......... The exploit worked flawlessly, providing the ability to run arbitrary code in kernel mode......... A slight twist is that the usual kernel shellcode that just steals the SYSTEM access token is not particularly useful to the attacker. Although the attacker gains SYSTEM rights in his user mode process, the process is still confined by Sandboxie (and an attempt to kill a nonsandboxed process from this SYSTEM shell fails). The attacker needs to perform some extra work while in kernel mode, either:

1) Disable the Sandboxie driver (uninstall hooks, or just overwrite the driver code)
2) Migrate to another process that runs outside of the Sandboxie container

We chose the second method, because it is more generic. The required steps are:

1) Allocate kernel memory for exploit_syscall_handler() function
2) Hook all system calls via overwriting LSTAR MSR, (LSTAR:= exploit_syscall_handler)
3) When the exploit_syscall_handler() function detects it is running in the context of a process running outside of the sandbox, inject arbitrary shellcode into this process.

The result is that after the exploit is run within a sandbox, the attacker can execute arbitrary code in the context of an arbitrary process. Careful readers certainly recognize that this procedure is similar to how remote kernel exploits (that often initially execute with raised IRQL) migrate to a stable user mode environment.

To sum up, we have verified that by exploiting the CVE-2012-0217 vulnerability, a Sandboxie-confined process can completely bypass Sandboxie protection.'

Cheers

 

The article pretty much states what I've stated a million times, and what should be known by now. A sandbox is only as powerful as the kernel enforcing it.

They mention Seccomp, which is nice, as it's currently the only significant progress towards a sandbox that makes a real difference (ie: a sandbox that isn't just '+1' vuln).

@Peter,

The first section is all about Sandboxie.

Also, this looks like it's related to Bromium, a project that sandboxes through hypervisor support - the goal being that hardware > kernel > application sandboxing.

I'm very satisfied with that paper. They actually noted the issues with HW virtualization, which I don't think most companies are willing to do.

Nothing in that PDF should be news to anyone though.

 

if u want 99.99% protection u need to isolate the whole OS=virtual machine
(my choice vmware player free without tools)

 

VM won't protect you either. This research is pretty relevant to that, as you essentially have a buggy and exploitable kernel being emulated by a buggy layer under it. It's another +1 vuln situation, but in this case you're not reducing attack surface at all, you're actually providing an even buggier system to go for.

 

Everything has breakpoints that can be exploited, and in my honest opinion this reflects poorly on the operating system and maybe even the hardware more so than it does the sandbox. Recognizing this limitation is important, but I wouldn't expect a third party application to protect something as critical as the system kernel. Just my opinion on the matter.

 

This reminds me a talk of HackinParis Conf
https://www.hackinparis.com/talk-escaping-windows-sandboxes
If Microsoft 0 days are the most expensive in the blackmarket, this is also because it provides more attack surface on a whole system: break the system and you can break the whole security infrastructure attached to this system...
This is valuable for any kind of security solution, from the AV to the sandbox and the VM.
When blogging in the past, i remember PoC of Ilya from Softsphere/DeefenseWall that breaks Buffer Zone security
http://www.trustware.com/forum/viewtopic.php?t=99
Non sceptical security minds that believe in Softwares as Security can read books like "Exploiting softwares, How to break code", practise their own defeating challenge against AV/HIPS/IDS, take a look at the history of Insecurity...
Vupen has also prooved chrome sandbox vulnerability, and they have certainly non published other 0 days...
I believe that sandbox and virtualization based HIPS like Sandboxie are the most malwares immune HIPS.
But if they can counter most malwares persistence, what could they do against BO, privilege escalation, Ring0 flaws etc...

Rgds

 

+1 Kareldjag +1 Hungryman

Policy containment and security programs based on isolation and virtualisation are the way to go.

If it would only be possible to quiet down all those sandboxie fanboys without addressing a good product like Sandboxie negatively.

 

lol, hard to do I suppose. The product is good. Support is good. Not too hard to understand. Provides a great level of security.

Hard to not be positive about a great product.

Sul.

 

I've tested a few exploits in a 'restricted' 64bit sandbox and they were unable to run; I'm assuming this exploit is no different...amirite?

 

software virtualization is okay most of the time but more susceptible to attack, than hardware virtualization

 

I wonder how the Qubes OS rates with Kareldjag and Hungryman with regard to sandboxing and security?

-- Tom

 

Let me try , PM them and ask to see how much I am wrong

a) Hungryman - over kill, unix has additional features which can be used first, focus on making those existing features/add-ons easier to use/implement would have more impact on security.

b) Kareldjag - no main stream, to much of a hassle to obtain a big audience in consumer market, to much an exotic OS to be considered in the corpotate market. Interesting though its software architecture could influence future Unix development (simular to Next OS influencing Apple OS).

Note (I agree with both).

 

Dead on.

edit: well, pretty much. I'd say they shouldn't focus on hypervisors for security - turtle paradox, and other issues.

I don't think they use any grsecurity/pax patches. Do they really expect to have some ultrasecure OS without the most important security software there ever has been? Eh.

Various other issues. Too cumbersome. They should find more elegant solutions to problems. Maybe I'm wrong, I'm waiting for a full release to really dig in.

 

You can fully block and fully prevent this vulnerability by using Sandboxie itself:
Resource Access > File Access > Blocked Access and add c:\windows\system32\t2embed.dll

However, this is no longer needed since Microsoft has fully patched this Windows vulnerability.

 

I had a quick look at your latest Safe Admin setup.
https://www.wilderssecurity.com/showpost.php?p=2225342&postcount=29988

If I read it correctly, you are using Chrome's native sandbox, but no other tools are used for virtualization, correct?

Is there any merit in running any of the browsers in a sandbox (e.g. Sandboxie), even if they are imperfect (as the pdf articulates)? Your comment here seems positive about Sandboxie:
https://www.wilderssecurity.com/showpost.php?p=2215311&postcount=114

Would running Sandboxie in a RAMDisk container help, or would it be just as productive to run the browser directly with a RAMDisk container of its own?

Also, it looks like you dropped ExploitShield and have added SpyShelter. Why the drop and what is superior with your add, if I might ask? I checked and couldn't find a specific comment to this.

 

In general YES, the benefit is bigger when the browser applies less containment by itself, so benefit for FF users is bigger as for IE users and for IE users bigger than for Chrome users. In the past adding a policy container or virtualisation sandbox was a NO-BRAINER, when one is capable of applying it, one should use it (back in XP IE6/7 days). Currently new OS-ses (e.g. Windows8 'tile' enhanced protected mode) and Browsers (Chrome's total sandbox isolation) and mitigation options (EMET) shift this no-brainer to 'depends on your personal preferences and other security measures'.

Well normal benefits of Ramdisk apply: faster and automated cleanup after reboot. Speed benefits depend on the browser you are using (Opera had a RAM option for temporary data), whether or not to add an additional layer also (see previous answer).

 

Good summary, thanks.

We are largely FF users, with some Chrome (though, if only out of ignorance, have a concern about it's possible link back to Google for data collection). We've read positive comments here about the latest IE and continue to research (though possible MS link back too - but we've had discussion on other threads about "leaks", so don't want to digress here). Never really considered Opera.

 

FYI Bromium Labs have posted what seems to be an expanded version of the above-mentioned report.

The later report can be found by visiting -http://labs.bromium.com/2013/07/23/application-sandboxes-a-pen-testers-perspective/-.

The bottom lime was that the ever-expanding nature of Windows provides an ever-expanding "attack surface" for the bad guys to bypass a sandboxed application. While we knew that already, it makes decisions about if/when to upgrade the Windows OS just that bit trickier.

I found the link from the Sandboxie forum but tzuk seems to have taken exception to something fairly major and deleted the whole thread because I can no longer find it.

 

Yup. That was discussed earlier on here:

https://www.wilderssecurity.com/showthread.php?t=350960

When I come to think of it, I think that thread deserves to be moved to this "sandboxing and virtualization" forum because it falls under the category after all and it would get better exposure that way.

The Sandboxie link: (it's no longer available; even with web cache tools it seems):
www.sandboxie.com/phpbb/viewtopic.php?t=16132‎

 

I wonder if this bypass would be harder with Windows 8. I think Windows 8 hardened the kernel.