Didier Stevens

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

Last year for Brucon, I produced some reverse engineering challenges (and I’m producing new ones for this year’s edition).

The Hex Factor blog posted the solution for level 300.

The source code for the challenge can be downloaded here. It’s completely written in assembler, even the I/O routines.

Here’s a trick I used to create your own EXE from assembler code, without any library:

A simple assembly program:

    BITS 32

    ret

Assemble with nasm: nasm -f win32 ret.asm -o ret.o

And link with mingw32‘s linker: ld -s ret.o -o ret.exe

Result: