Skip to main content
MSRC

Understanding DEP as a mitigation technology part 2

In our previous blog post, we explained how DEP works and how to determine if / how a process opted-in to DEP. Now we will demonstrate how DEP can be used to mitigate the risk of a real-world attack.

We published a security advisory in February describing an Excel vulnerability in fully-patched Excel being used in limited targeted attacks. As we noted in the SRD blog, the exploits target Office 2007 running on Windows XP. We will demonstrate now how to opt Excel in to DEP to help mitigate attempts to exploit this vulnerability.

First, why does Excel not opt-in to DEP by default?

If you look at the sysmain.sdb on Windows XP SP2 or the “DLL Characteristics” header value of iexplore.exe (IE 7) or excel.exe (or any Office application) you can see that these processes do not opt-in to DEP by default. Both IE 7 and Office do not opt-in to DEP for the sake of 3rd party extensions and plug-ins that need to run inside IE and Office applications. IE and the Office applications themselves work fine with DEP enabled so if you don’t need to use older 3rd party extensions, you might be able to get away with opting these processes in to DEP.

There are three different ways you could use to opt excel.exe in to DEP:

  • Use the Application Compatibility Toolkit to create an AppCompat database for Excel, install it using sdbinst.exe (Windows XP SP2 / Windows Server 2003 SP1 and higher), or
  • Change the system-wide DEP policy to either ‘OptOut’ or ‘AlwaysOn’ (potential compatibility risk *)
  • Use the ExecuteOptions registry setting (Windows Vista or Windows Server 2008, potential compatibility risk *)

(*) The system-wide ‘AlwaysOn’ setting and the ExecuteOptions registry setting do not allow DEP to be disabled for a process once it has been enabled which can lead to a DEP related crash in Office applications if those applications attempt to make use of VBA or macros, therefore the safest option from an application compatibility perspective is to use the Application Compatibility Toolkit to opt a process into DEP, which is discussed in more detail below.

Using the Application Compatibility Toolkit on XP SP2 / Server 2003 SP1 and newer

Creating an entry in the Application Compatibility Database targets only the affected application so you can leave the default system-wide DEP set to “OptIn”. This is the most targeted, least risky solution on Windows XP SP2 and Server 2003 SP1 and newer. Detailed information on exactly how to create an AppCompat database for Excel can be found near the bottom of this article on mitigating application compatibility (search for “Enabling DEP for an application”).

After following the steps in the above article and supplying the path to EXCEL.EXE in step 2 you should get to a screen that looks like this:

Now an appcompat fix for Excel has been created and if this fix is installed - the AppCompat layer will target processes named EXCEL.EXE that have a file description field containing “Microsoft Office Excel” and a “Company Name” of “Microsoft Corporation”. You can add additional matching criteria / attributes or remove those to target all processes named EXCEL.EXE. In our example, this AppCompat fix is saved in c:\temp\enable_DEP_excel.sdb. To deploy this database to a system run “sdbinst.exe –q c:\temp\enable_DEP_excel.sdb” as an administrator. The changes takes effect immediately and can be deployed in an enterprise via SMS or machine startup script.

NOTE: If Excel does not seem to be running with DEP enabled after deploying the SDB, make sure that the Compatibility Administrator was run with the ‘/x’ switch. You will only see the circled ‘Parameters’ button and be able to enter the appropriate “Command line” value (circled below) if you start the Compatibility Administrator with the /X command line switch. If you didn’t do this the first time around, you can right-click on ‘Excel.exe’ in the right pane of the Compatibility Administrator and choose ‘Edit Application Fix’ after launching the Compatibility Administrator with the /X command line switch to fix it at any time (as shown below).

If you simply want to enable DEP for your Office applications but don’t want to download the Application Compatibility Toolkit - we have created an Application Compatibility Database file that will enable DEP for all of the Office Professional suite of applications. To install this application compatibility database you can click the FixIt4Me button below:

Click Here To Enable DEP for Office!

To uninstall the application compatibility database you can click the Fixit4Me button below:

Click Here To Disable DEP for Office!

We have also created an application compatibility database that will enable DEP for all versions of Internet Explorer (this is not needed if you are using Internet Explorer 8 on XPSP3 or Vista SP1 or later as IE8 opts-in to DEP by default on these platforms). To install this application compatibility database you can click the Fixit4Me button below:

Click Here To Enable DEP for IE!

To uninstall the application compatibility database you can click the Fixit4me button below:

Click Here To Disable DEP for IE!

Use the ExecuteOptions registry setting (Windows Vista or Windows Server 2008)

On Windows Vista and Windows Server 2008, there is an easier way. The following registry script run with admin privs will cause Excel to opt-in to DEP without needing to use the AppCompat database though with a slightly higher risk of application compatibility problems if VBA / macros are used in your environment.

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\excel.exe]
"ExecuteOptions"=dword:00000000

Demo: DEP & the Excel 0-day vulnerability

With DEP enabled for Excel 2007 running on an unpatched Windows XP SP2 machine, we tried double-clicking one of the malicious XLS files that attempt to exploit the Excel 0-day vulnerability. Without DEP, this results in reliable code execution. After enabling DEP, we expect the exploit to be blocked. Let’s take a look:

Debugging the crash we see that an access violation was raised as soon as the exploit triggered code execution on a non-executable page of memory:

0:000> r
Last set context:
eax=001363c0 ebx=02f45800 ecx=001363b8 edx=009c2404 esi=02fce05c edi=00000000
eip=001363c0 esp=0013608c ebp=00136374 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010246
0x1363c0:
001363c0 eb1c            jmp     0x1363dd (001363de)
0:000> kv
  *** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr  Args to Child
WARNING: Frame IP not in any known module. Following frames may be wrong.
00136088 3006853a 02fce05c 0232f204 301f736c 0x1363c0
00136374 303eeb6e 02f45800 fd010008 00010019 EXCEL!Ordinal40+0x6853a
00138658 3019f8b7 00000005 02fc3a28 0013b7b8 EXCEL!Ordinal40+0x3eeb6e
00138704 301a3a4c 00138ed4 0013b7b8 0013b5b4 EXCEL!Ordinal40+0x19f8b7
0013b9d4 301a27a4 0013cd6c 00000826 00000001 EXCEL!Ordinal40+0x1a3a4c
0013dfcc 301a2b85 0013ebf4 00000012 00000000 EXCEL!Ordinal40+0x1a27a4
0013e2a0 301a2ea1 0013ebf4 00000012 00000000 EXCEL!Ordinal40+0x1a2b85
0013e55c 3018c1fa 00000000 0013ebf4 00000012 EXCEL!Ordinal40+0x1a2ea1
0013e580 30030075 0013ebf4 00000012 00000000 EXCEL!Ordinal40+0x18c1fa
0013e7d0 30937c19 00000001 0013ebf4 00000012 EXCEL!Ordinal40+0x30075
0013f890 30d146a6 001a1360 0013f904 00020000 EXCEL!Ordinal40+0x937c19
0013fd38 303ceace 0013fd9c 00000001 000080df EXCEL!LPenHelper+0x12e041
0013fdd8 3002788a 00000000 30f08430 7e418e28 EXCEL!Ordinal40+0x3ceace
0013fec0 30003ae8 00000000 30f08974 00162348 EXCEL!Ordinal40+0x2788a
0013ff30 300037fc 30000000 00000000 00162348 EXCEL!Ordinal40+0x3ae8
0013ffc0 7c817067 0018c28a 00daef68 7ffd6000 EXCEL!Ordinal40+0x37fc
0013fff0 00000000 30002efc 00000000 78746341 kernel32!BaseProcessStart+0x23 (FPO: [Non-Fpo])
0:000> !vprot 001363c0
BaseAddress:       00129000
AllocationBase:    00040000
AllocationProtect: 00000004  PAGE_READWRITE
RegionSize:        00017000
State:             00001000  MEM_COMMIT
Protect:           00000004  PAGE_READWRITE
Type:              00020000  MEM_PRIVATE
0:000> !analyze -v
*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************
<snip>

FAULTING_IP:
tyle+1363bf
001363c0 eb1c            jmp     0x1363dd (001363de)

EXCEPTION_RECORD:  00135da4 -- (.exr 0x135da4)
ExceptionAddress: 001363c0 (0x001363c0)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000008
   Parameter[1]: 001363c0
Attempt to execute non-executable address 001363c0</snip>

You can see that the system raised an access violation attempting to execute code from a non-executable (PAGE_READWRITE) address. DEP saves the day!

- Robert Hensing, MSRC Engineering

*Posting is provided “AS IS” with no warranties, and confers no rights.*


Related Posts

How satisfied are you with the MSRC Blog?

Rating

Feedback * (required)

Your detailed feedback helps us improve your experience. Please enter between 10 and 2,000 characters.

Thank you for your feedback!

We'll review your input and work on improving the site.