SandWorm’s target: A patch history of Object Packager

[Nytro]

SandWorm’s target: A patch history of Object Packager

Matt_Oh| November 20, 2014

Last Patch Tuesday (that is, November 11, 2014), Microsoft released MS14-064, a security patch for a SandWorm 0-day vulnerability. They had also previously patched the vulnerability with the October patch Tuesday release (MS14-060) but malware samples working around the fix were subsequently found in the wild.

Interestingly, the affected module, Object Packager, had suffered a similar issue in 2012 with security bulletin MS12-005. That issue was about remote code execution using the ClickOnce functionality embedded in Microsoft Office files. The issues with the latest two patches this year concern remote code execution with INF or EXE files embedded in Microsoft Office files; only the type of embedded object differs. When I looked into the patch, I found striking similarities between them. Here are my findings.

Marking files unsafe

One of the main similarities between the patches is with the zone identifier. Both MS12-005 and MS14-060 add code to mark files unsafe by using a zone identifier. This pops up a warning dialog box on the user’s screen before binaries are executed. This provides additional protection for the user - any embedded object dropped in the temporary folder from Office documents should be treated as potentially dangerous.

How MarkFileUnsafe works

To understand what the MarkFileUnsafe function does, I opened packager.dll up in IDA. After a bit of debugging, I found that it uses the CZoneIdentifier object to set the zone identifier ID to 3 (URLZONE_INTERNET), as we see in Figure 1.The zone identifier concept was first introduced with Windows XP SP2 and it uses an Alternative Data Stream file, Zone.Identifier, to mark a file’s origin. For example, if a file was downloaded from the Internet through a web browser, it would be marked with ‘ID 3’ which corresponds to URLZONE_INTERNET. For a good explanation of the CZoneIdentifier, see this blog post from Microsoft.

Figure 1 Calling CZoneIdentifier::SetId with argument 3 (URLZONE_INTERNET)

Marking the file with ID 3 means that the file is treated as unsafe. When it is executed, it triggers a user confirmation dialog that looks like the one shown in Figure 2. This is a road block to malware or exploits that may try to abuse the related feature.

Figure 2 Security Warning dialog

CVE-2014-4114

The CVE-2014-4114 vulnerability used in the SandWorm operation was fixed mainly by marking dropped files unsafe (as I explained in my previous blog post). Figure 3 shows three functions that have been patched by adding a call to the MarkFileUnsafe function. The whole point of the MS14-60 patch was to mark dropped files as unsafe.

Figure 3 Three functions patched with the addition of the MarkFileUnsafe function call

CVE-2012-0013

An interesting fact is that a similar patch to other functions with similar functionality had been performed in 2012 with MS12-005. It fixed the CVE-2012-0013 vulnerability, which allowed execution of the ClickOnce application embedded in Microsoft Office files.

Looking at Figure 4 you can see that the MarkFileUnsafe function was added to the patched packager.dll file.

Figure 4 Patched functions with MS12-002

Some of the patched functions, including CPackage::CreateTempFile and CPackage::EmbedreadFromStream introduced a call to MarkFileUnsafe just after copying the file to the temporary folder, as shown in Figure 5.

Figure 5 Addition of a call to MarkFileUnsafe

Similar issues in the same function - CPackage::DoVerb

Somehow, one specific function, CPackage::DoVerb, is a ‘hot zone’ which is patched again and again. The reason for this is that this is the main function where all the external command and object handling occurs using shell extensions and COM interfaces.

CVE-2014-6352

A ‘verb’ is the term used to describe a case where a command string is passed through the Object Packager to an external component. The original intended purpose of the Object Packager from Office was mostly to play animation with graphics and sound. This verb can be used to pass various commands to the non-OLE component. Verb commands are basically strings like “play”, “pause” and “resume”, etc. but there are two special defined verb values: “0” and “1”. The first, “0” means open the object for editing while “1” means open the object for “viewing”. This MSDN article has a good description of this feature. However, it looks like you also can pass other numbers that perform additional operations, including running linked programs with the attachment itself as the input.

Figure 6 Show OK/Cancel message box

Figure 6 shows how this vulnerability was fixed. It displays an additional message box before it calls the InvokeCommand method from the CDefFolderMenu class in shell32.dll. The message box can be turned off if you set a special registry key, as shown in Figure 7. To fix it, they made opt-out the default behavior for this function.

Figure 7 Retrieve registry value

CVE-2012-0013

CVE-2012-0013 also had a patch on this same method – CPackage::DoVerb. When the ClickOnce application was embedded inside a Microsoft Office file, it could bypass the special check in the Object Packager. Figure 8 and Figure 9 show the GiveWarningMsg methods called just before dangerous operations like ActivateEmbeddedFile or ShellExecuteExW that launch external programs are performed.

Figure 8 Unpatched code with the GiveWarning call

Figure 9 Unpatched code with the GiveWarning call

The approach with unpatched code used a blacklist of file extensions, as Figure 10 shows. Figure 11 shows part of the GiveWarningMsg function. It passed a blacklist of extensions to the sub-function to compare. If the file’s extension was on this list, it did not pass through to the following dangerous operations.

Figure 10 Extension black list

Figure 11 Check extension black list

But, it looks like this blacklist didn’t cover every possible dangerous extension, and ClickOnce was one of those. The patch from the vendor solves this problem by ditching the blacklist approach, instead using an opt-in registry key. If you don’t set a specific registry key, you will not be allowed to run any dangerous APIs by default, as shown in Figure 12.

Figure 12 Checking opt-in registry key

For example, based on this registry key, ShellExecuteEx will either be allowed or not, as we see in Figure 13. The point is that by default, the dangerous operation is blocked. This is a similar approach to how CVE-2014-6352 was solved using a default opt-out approach.

Figure 13 By default, show message and exit

Conclusion

So, packager.dll has gone through three rounds of patching over the last few years: MS12-005, MS14-060 and MS14-064. MS12-005 fixed the CVE-2014-0013 ClickOnce issue. MS12-005 and MS14-064 cover a special verb command issue.

The problem is that the three patches touch on the same issues over and over again. MS12-005 introduced the MarkFileUnsafe function and applied it to two functions. Now MS14-060 applies the same patches to an additional three functions that perform very similar actions – file dropping. MS12-005 fixed an extension validation issue in the CPackage::DoVerb function by introducing a special registry key switch. MS14-064 fixed a very similar issue inside the exact same function by introducing a special registry key and confirmation message box. MS12-005 fixed a dangerous call to the ShellExecuteExW API and MS14-064 fixes dangerous usage of the IContextMenu interface, which can be abused to run arbitrary commands through the extension context menus functionality. Using the IContextMenu interface to launch remote code execution isn’t obvious at first, but allowing a COM call to the shell component doesn’t sound so secure either.

Based on my findings, I think there was a good chance to fix the SandWorm vulnerability two years ago, before it was used by malware authors and became an issue. We can’t reverse time, but we can, and should, learn from the past.

Sursa: SandWorm’s target: A patch history of Object Packa... - HP Enterprise Business Community

Edited November 22, 2014 by Nytro