Here’s another tool to mitigate exploitation of vulnerable (office) applications.
I discovered Job Objects in this book. Job objects allow processes to be grouped and managed together.
An interesting aspect of job objects for securing applications is the ActiveProcessLimit property. With this, you can limit the number of processes running inside the job object. Set this limit to 1 and run an office application inside the job object, and the office application will not be able to start another program. Because once a process is assigned to a job object, all its child processes are also assigned to the job object. Processes can’t change the limits of the job object they are running in, and once a process is assigned to a job object, it can’t be removed from this job object or assigned to another job object. So once a process is assigned to a job object, it is trapped inside and constrained by the limits of the job object.
To prevent a vulnerable application from launching malware, put the vulnerable application inside a job object and limit the number of processes to 1. And the good news is that job objects were introduced with Windows 2000, so this works on Windows XP too.
RunInsideLimitedJob is a program I wrote to constrain programs with a job object. There are 2 versions: an .EXE and a .DLL.
RunInsideLimitedJob.exe takes one argument: the program you want to restrict. It creates a new job object, restricts the number of processes to 1, starts the program you passed as an argument and assigns it to the new job object. If you want to allow more than 1 process, use option -n.
While RunInsideLimitedJob.exe is for new processes, RunInsideLimitedJob.dll is for existing processes. When this DLL is loaded in a running process, it will create a new job object, restrict the number of processes to 1, and assign its host process to the new job object (assuming the host process is not yet assigned to a job object).
There are several ways to automatically load RunInsideLimitedJob.dll in your favorite office application, like my tool LoadDLLViaAppInit or by importing RunInsideLimitedJob.dll’s dummy function as explained here.
Here I started notepad inside a restricted job object, and then tried to start calc.exe from notepad.exe (via the open file dialog box):
Process Explorer supports job objects. It highlights processes assigned to job objects in brown, and it adds a Job tab to the properties of these processes.
If you try this with my tool, you won’t see the process highlighted brown or the Jobs tab in Process Explorer. Process Explorer does not display the job info when the handle to the job has been closed (the screenshots above are with a modified version of my tool that doesn’t exit and leaves the job handle open). I don’t know yet if this is a bug or a feature in Process Explorer. I need to find out.
The runas command also uses job objects, and these do appear in Process Explorer.
Download:
RunInsideLimitedJob_V0_0_0_1.zip (https)
MD5: 90055BA2928D06EC7A883DEF6E7F37C6
SHA256: EF88A2963436F5893727A90413CE624B473352190E936E35EEF85E246655486D
Didier Stevens 
IIRC, Job Objects are a key tool in the sandboxes beig used by Microsoft for Office, Google for Chromium and now for by Adobe for Reader.
What do Google and others do when they want to sandbox on other operating systems that don’t have these facilities built-in?
Comment by Larry Seltzer — Monday 13 September 2010 @ 20:35
@Larry Seltzer I don’t know, but Microsoft and Adobe don’t try sandboxing on other OSs. And I believe there is also a quota mechanism for processes on Linux.
Comment by Didier Stevens — Monday 13 September 2010 @ 21:06
Greate tool with a one great disadvantage. Started application have no command-line parameters support.
Comment by visitor — Tuesday 14 September 2010 @ 7:22
@visitor You use the DLL version for this. Example: Adobe Reader started by double-clicking a PDF document. When you do this, Windows Explorer will start Adobe Reader with the name of the PDF document as a command-line parameter. To force Adobe Reader to run inside a job, you load the DLL version in Adobe Reader like I referenced in the post.
Comment by Didier Stevens — Tuesday 14 September 2010 @ 7:32
Visitor- or, you can do it like that:
RunInsideLimitedJob.exe “notepad.exe 123.txt”
or:
RunInsideLimitedJob.exe -n 2 “cmd.exe /c calc.exe”
Comment by cp77fk4r — Wednesday 15 September 2010 @ 0:19
Any chance of combining this with the restrict-ACL capability in DropMyRights, to avoid having to run RunInsideLimitedJob inside DropMyRights, or the other way round? The source code is at http://msdn.microsoft.com/en-us/library/ms972827.aspx.
Comment by Dave — Friday 17 September 2010 @ 7:37
[…] RunInsideLimitedJob – didierstevens.com Here’s another tool to mitigate exploitation of vulnerable (office) applications. […]
Pingback by Week 37 in Review – 2010 | Infosec Events — Monday 20 September 2010 @ 7:26
[…] RunInsideLimitedJob – didierstevens.com Here’s another tool to mitigate exploitation of vulnerable (office) applications. […]
Pingback by Week 37 in Review – 2010 | Portable Digital Video Recorder — Monday 20 September 2010 @ 12:56
Depending on the job restrictions, it might be possible to escape the job (CREATE_BREAKAWAY_FROM_JOB) This is useful if you need to open a url from a uninstaller since the add/remove programs applet traps you in a job.
Also, runas does not really use job objects, it is a side effect of CreateProcessWithLogon/CreateProcessAsUser IIRC
Comment by WndSks — Wednesday 22 September 2010 @ 20:47
These links might interest you:
http://blogs.adobe.com/asset/2010/07/introducing-adobe-reader-protected-mode.html
http://blogs.msdn.com/b/david_leblanc/archive/2007/07/27/practical-windows-sandboxing-part-1.aspx
http://blogs.msdn.com/b/david_leblanc/archive/2007/07/30/practical-windows-sandboxing-part-2.aspx <– talks about Job objects as you are using here
http://blogs.msdn.com/b/david_leblanc/archive/2007/07/31/practical-windows-sandboxing-part-3.aspx
Comment by clint — Tuesday 28 September 2010 @ 5:14
[…] RunInsideLimitedJob is a tool to sandbox applications by containing their process inside a limited job object. There are 2 versions of my RunInsideLimitedJob tool: a .EXE and a .DLL. […]
Pingback by RunInsideLimitedJob 64-bit « Didier Stevens — Thursday 20 October 2011 @ 6:01
Is it possible to modify an existing Job Object. For example, when you open a PDF using AcroRd32, the process starts another limited AcroRd32 process that has a job object. Lets say I wanted to increase the limitations e.g. add a limit to clipboard access. Can I query the job object and add additional limitations? My gut says no as this would mean a person (attacker) could simply remove them.
Comment by Jason Coleman — Saturday 21 July 2012 @ 17:33
@Jason Job Objects offer a lot of flexibility. They can be modified. But to put it simply: a process that is running inside a Job Object can not modified that Job Object.
Comment by Didier Stevens — Tuesday 24 July 2012 @ 9:21
Thanks. I notice that the Acrobat Process has an unnamed job – i don’t think you can mess with those. At least I have not been able to… I can get a proper handle to a named job object though.
Comment by Jason — Tuesday 24 July 2012 @ 12:03
@Jason That job is part of the Adobe Reader X sandbox.
Comment by Didier Stevens — Wednesday 25 July 2012 @ 6:54
@Didier I know. I wanted to augment the existing security (for a project) by adding a Limit to clipboard writing. Oh, well.
Comment by Jason — Wednesday 25 July 2012 @ 12:06
@Didier: Thanks for the answers. I have two choices now: 1) Removed the protected mode setting from Acrobat (not a good idea) or 2) Hook SetClipboardData() in the target process and prevent its execution from completing. Option 2 sounds better.
Thanks
J
Comment by Jason — Wednesday 25 July 2012 @ 12:11
@Jason OK, now I see what you want to do. It is possible to modify the job of the Adobe sandbox to limit write clipboard. If you’re interested in my code, I’ll write a blogpost.
Comment by Didier Stevens — Tuesday 31 July 2012 @ 15:40