Total Members: 14197
Posted by: Pez
« on: 12. November 2013., 10:08:11 »Solving the Mystery of the Office Zero-Day Exploit and DEP
On November 5 McAfee Labs blogged about a Microsoft Office zero-day (See above) attack that we spotted in the wild. In another post we discussed coverage for our various products. Now, we’d like to report some interesting technical findings from our research team.
As pointed out in our previous post (See above), we found the exploit works pretty well on Office 2007 running Windows 7. We originally thought there must be some technique used by the exploit to bypass address space layout randomization and data execution prevention. However, our findings show something different because of the DEP system policy setting.
While debugging the shellcode, we noticed quite a few interesting things. First, the shellcode was in a PAGE_READWRITE memory block, which encouraged us to further check the DEP status of the process winword.exe. We found the DEP status was “on” at the process start but “off” during shellcode execution.
McAfee Labs researcher Haifei Li found this exploit worked on system-level DEP options, including both the Opt-In and Opt-Out for Office 2007. If the system policy is set to Opt-In, DEP is enabled only for processes that explicitly opt-in to DEP. Office 2007 Word is not in the DEP-enabled list; thus DEP is not enabled for Office 2007 under the Opt-In mode and there is no need for an exploit to bypass DEP to succeed. We tested further for the Opt-Out mode. If the system policy is set to Opt-Out, DEP is enabled by default for all processes except those that explicitly opt out of DEP. That means usually DEP is on for all processes for this option when they start, but a process has the option to opt out of DEP at any moment. We figured out that if we blocked the loading of VBE6.DLL (C:\Program Files\Common Files\Microsoft Shared\VBA\VBA6\VBE6.DLL), the exploit would not work–a DEP-violation error was triggered. Also, if we forced DEP with Microsoft EMET, the exploit would not work.
The test results caused us to wonder whether there was a DEP bypass, such as using ROP gadgets. Though many other researchers claimed this point after their analysis, they might have analyzed different samples. (The MD5 hash for our analyzed sample is 1FD4F3F063D641F84C5776C2C15E4621.)
Quickly we injected our DLL in winword.exe with a hooked LoadLibraryExA and called GetProcessDEPPolicy before and after the loading of each module. We opened the log and found that DEP status changed to “off” just after the loading of VBE6.DLL. After some investigation we I found that ntdll!ZwSetInformationProcess can be called with parameters -1 and 0×22 to turn off DEP for the process. So, just before the call to LoadLibrary with VBE6.DLL, we set a break point at ntdll!ZwSetInformationProcess, and it got hit with the expected parameters (-1,0×22). Back-tracing the call, we came across this:
("click the images to make them larger")
This is the code to disable DEP for the process:
This solves the mystery of the exploitation. Our analyzed exploit didn’t bypass ASLR and DEP. Instead, it leveraged a backward compatibility feature in Office 2007 to disable DEP. Without DEP, ASLR is quite easy to bypass with heap spraying, as discussed in this Microsoft SRD post.
We believe that the DEP compatibility issue of old DLLs such as VBE6.DLL makes this exploitation possible. Microsoft’s guidance confirmed our suspicions. The DEP system policy can be set to Opt-In, Opt-Out, Always-On, and Always-Off. Only the Always-On option enforces DEP, which means that a process cannot turn off DEP. For compatibility reasons, the Always-On setting may cause DEP-related crashes due to Microsoft Office applications opening documents that contain Visual Basic for Applications macros.
The lesson we learned is interesting. For better security, the system setting for DEP should be Always-On. But for compatibility, Opt-Out can be used to protect applications that assume DEP availability. However, the Opt-Out system setting does not necessarily have full DEP protection for an application that does not explicitly opt out of DEP; thus such an application (Microsoft Word in this case) is still subject to exploits that may be prevented by DEP.
Original article: By Vinay Karecha on Nov 07, 2013
On November 5 McAfee Labs blogged about a Microsoft Office zero-day (See above) attack that we spotted in the wild. In another post we discussed coverage for our various products. Now, we’d like to report some interesting technical findings from our research team.
As pointed out in our previous post (See above), we found the exploit works pretty well on Office 2007 running Windows 7. We originally thought there must be some technique used by the exploit to bypass address space layout randomization and data execution prevention. However, our findings show something different because of the DEP system policy setting.
While debugging the shellcode, we noticed quite a few interesting things. First, the shellcode was in a PAGE_READWRITE memory block, which encouraged us to further check the DEP status of the process winword.exe. We found the DEP status was “on” at the process start but “off” during shellcode execution.
McAfee Labs researcher Haifei Li found this exploit worked on system-level DEP options, including both the Opt-In and Opt-Out for Office 2007. If the system policy is set to Opt-In, DEP is enabled only for processes that explicitly opt-in to DEP. Office 2007 Word is not in the DEP-enabled list; thus DEP is not enabled for Office 2007 under the Opt-In mode and there is no need for an exploit to bypass DEP to succeed. We tested further for the Opt-Out mode. If the system policy is set to Opt-Out, DEP is enabled by default for all processes except those that explicitly opt out of DEP. That means usually DEP is on for all processes for this option when they start, but a process has the option to opt out of DEP at any moment. We figured out that if we blocked the loading of VBE6.DLL (C:\Program Files\Common Files\Microsoft Shared\VBA\VBA6\VBE6.DLL), the exploit would not work–a DEP-violation error was triggered. Also, if we forced DEP with Microsoft EMET, the exploit would not work.
The test results caused us to wonder whether there was a DEP bypass, such as using ROP gadgets. Though many other researchers claimed this point after their analysis, they might have analyzed different samples. (The MD5 hash for our analyzed sample is 1FD4F3F063D641F84C5776C2C15E4621.)
Quickly we injected our DLL in winword.exe with a hooked LoadLibraryExA and called GetProcessDEPPolicy before and after the loading of each module. We opened the log and found that DEP status changed to “off” just after the loading of VBE6.DLL. After some investigation we I found that ntdll!ZwSetInformationProcess can be called with parameters -1 and 0×22 to turn off DEP for the process. So, just before the call to LoadLibrary with VBE6.DLL, we set a break point at ntdll!ZwSetInformationProcess, and it got hit with the expected parameters (-1,0×22). Back-tracing the call, we came across this:
("click the images to make them larger")
This is the code to disable DEP for the process:
This solves the mystery of the exploitation. Our analyzed exploit didn’t bypass ASLR and DEP. Instead, it leveraged a backward compatibility feature in Office 2007 to disable DEP. Without DEP, ASLR is quite easy to bypass with heap spraying, as discussed in this Microsoft SRD post.
We believe that the DEP compatibility issue of old DLLs such as VBE6.DLL makes this exploitation possible. Microsoft’s guidance confirmed our suspicions. The DEP system policy can be set to Opt-In, Opt-Out, Always-On, and Always-Off. Only the Always-On option enforces DEP, which means that a process cannot turn off DEP. For compatibility reasons, the Always-On setting may cause DEP-related crashes due to Microsoft Office applications opening documents that contain Visual Basic for Applications macros.
The lesson we learned is interesting. For better security, the system setting for DEP should be Always-On. But for compatibility, Opt-Out can be used to protect applications that assume DEP availability. However, the Opt-Out system setting does not necessarily have full DEP protection for an application that does not explicitly opt out of DEP; thus such an application (Microsoft Word in this case) is still subject to exploits that may be prevented by DEP.
Original article: By Vinay Karecha on Nov 07, 2013
