Attacker Value
Unknown
(1 user assessed)
Exploitability
Unknown
(1 user assessed)
User Interaction
Unknown
Privileges Required
Unknown
Attack Vector
Unknown
0

Microsoft Internet Explorer Use-After-Free Vulnerability

Disclosure Date: October 15, 2014 Last updated February 13, 2020
Exploited in the Wild
Add MITRE ATT&CK tactics and techniques that apply to this CVE.

Description

Microsoft Windows Vista SP2, Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8, Windows 8.1, Windows Server 2012 Gold and R2, and Windows RT Gold and 8.1 allow remote attackers to execute arbitrary code via a crafted OLE object in an Office document, as exploited in the wild with a “Sandworm” attack in June through October 2014, aka “Windows OLE Remote Code Execution Vulnerability.”

Add Assessment

1
Technical Analysis

SETUP

  • Windows 7 SP1
  • Office 2013 (full install)
  • packager.dll 6.1.7600.16385 (Mon Jul 13 20:09:25 2009)

Details

CVE-2014-4114, also known as Sandworm, is a vulnerability found in Windows OLE that allows remote
code execution. It was found in the wild as a PowerPoint file, originally discovered by ESET, and
was patched on Oct 14, 2014.

The vulnerability has to do with how the Object Packager 2 (packager.dll) component handles an
INF file that contains malicious registry changes, which can lead to code execution. First of all,
Packager cannot load the INF file directly, but you can trick it to load your INF file anyway
by embedding the file path as a remote share in an OLE object. When it’s embedded as an OLE object,
it’s possible to make Packager to treat your malicious file as a media file. There are 6 media
formats supported: SOUNDREC, OLE1SOUNDREC, MPlayer, OLE1MPlayer, AVIFile, MIDFile. The MPlayer
format is the one to go for our case, because this will be loaded by the
packager!CPackage::OLE2MPlayerReadFromStream function, which also triggers a CopyFileW call. The
CopyFileW function will download the malicious file from the remote share, save it under the
temp folder, and then pass that information that will be used later.

The following callstack can illustrate the work flow of the loading process:

ChildEBP RetAddr
0029eb98 6ff94b85 packager!CPackage::CreateTempFileName
0029ebb0 6ff94f0a packager!CPackage::OLE2MPlayerReadFromStream+0x118
0029ec14 6ff9665c packager!CPackage::LoadMMStorage+0xe5
0029ec48 75bceb44 packager!CPackage::Load+0xbb
0029ecb8 75bcf2af ole32!wCreateObject+0x1fc [d:\w7rtm\com\ole32\ole232\base\create.cpp @ 3108]
0029ed1c 75bcf1d4 ole32!OleLoadWithoutBinding+0x9c [d:\w7rtm\com\ole32\ole232\base\create.cpp @ 1576]
0029ed44 60c6d608 ole32!OleLoad+0x37 [d:\w7rtm\com\ole32\ole232\base\create.cpp @ 1495]

The actual exploit will try to abuse the above loading routine twice: The first is the fake gif
file, and the other is the INF file. The purpose of that is to make INF file rename the gif one
to .exe, which will happen later.

After the streams are loaded, the Packager component will also look at each OLE object’s command
node in their XML file (in the exploit in the wild, this can be found in slide/slide1.xml), and
determine what media command needs to happen. These media commands are also known as the
“XML Presentation Command class”, which is described in the following:
http://msdn.microsoft.com/en-us/library/documentformat.openxml.presentation.command(v=office.14).aspx

The command class/node is presented as the following XML syntax:

<p:cmd type="type" cmd="cmd">

From the above syntax, there are two important properties: “type” and “cmd”. We’ll explain what
each does.

The type property supports the following:

  • call – Used to call methods on the object specified (play(), pause(), etc.)
  • evt – Used to set an event for the object at this point in the timeline (onstopaudio, etc.)
  • verb – Used to set verbs for the object to occur at this point in the timeline (0, 1, etc.)

The cmd property supports the following:

  • call – play corresponding media
  • play – play corresponding media starting from s, where s is the number of seconds from the
    beginning of the clip.
  • pause – pause corresponding media
  • resume – resume play of corresponding media
  • stop – stop play of corresponding media
  • togglePause – play corresponding media if media is already paused, pause corresponding media if
    media is already playing. If the corresponding media is not active, this command
    restarts the media and plays from its beginning.
  • onstopaudio – stop play of all audio

However, when you’re using the verb type, you have the following commands:

  • 0 – Open the object for editing
  • 1 – Open the object for viewing
  • 3 – Undocumented. But this is what the exploit is using to get the inf to run.

Note that the exploit uses two OLE objects, so there are two commands for each. The first one is
for the fake slide1.gif file. It uses the “verb” type, with cmd of “-3”:

<p:cmd type="verb" cmd="-3">
...
</p:cmd>

The inf file also uses the "verb" type, but with cmd of "3":

<p:cmd type="verb" cmd="3">
...
</p:cmd>

The reason the “verb” type is used is because this will trigger the packager!CPackage::DoVerb
function in the Packager component. When this function sees the slide1.gif file, it will bail right
away due to the -3 cmd. We don’t want it to do anything. However, when the function sees the INF
file, which uses cmd 3, it will ask Windows to find the appropriate handler, which will give us
C:\Windows\System32\infDefaultInstall.exe, and that process will be used to install our malicious
INF file via a CreateProcessW call, and then results in arbitrary code execution.

The following callstack should illustrate the work flow that leads to code execution:

ChildEBP RetAddr
0029db78 767e55c1 kernel32!CreateProcessW
0029dc70 767f2bda SHELL32!_SHCreateProcess+0x251
0029dcc4 767e53c5 SHELL32!CExecuteApplication::_CreateProcess+0xfc
0029dcd4 767e5379 SHELL32!CExecuteApplication::_TryCreateProcess+0x2e
0029dce4 767e47d1 SHELL32!CExecuteApplication::_DoApplication+0x48
0029dcf4 767ff6b1 SHELL32!CExecuteApplication::Execute+0x33
0029dd14 767e4a1c SHELL32!CExecuteAssociation::_DoCommand+0x88
0029dd38 767ff733 SHELL32!CExecuteAssociation::_TryApplication+0x41
0029dd58 76800ff1 SHELL32!CExecuteAssociation::Execute+0x5f
0029dd88 76800f22 SHELL32!CRegDataDrivenCommand::_Invoke+0xe2
0029dd9c 76801175 SHELL32!CRegDataDrivenCommand::InvokeFromContextMenu+0x18
0029ddc8 768010d8 SHELL32!CRegistryVerbsContextMenu::_Execute+0x5a
0029e03c 7680056c SHELL32!CRegistryVerbsContextMenu::InvokeCommand+0xa4
0029e0c0 76800444 SHELL32!HDXA_LetHandlerProcessCommandEx+0x132
0029e3a0 6ff95ee0 SHELL32!CDefFolderMenu::InvokeCommand+0x1ca
0029ee6c 66a62eea packager!CPackage::DoVerb+0x374

OTHER INTERESTING THINGS FOUND DURING REVERSING

  • The DoVerb function is also where the bug was for MS12-005 (Microsoft ClickOnce Vulnerability).
    That vuln was due to the CPackage::_GiveWarningMsg function using a weak list of dangerous/executeable
    files (such as a Python file, Ruby, etc).

  • Before the INF is run, a “Zone Check” will trigger by shell32. This means it is possible to
    cause the exploit to fail if the target machine has very strict IE zone settings.

  • For some reason, the exploit seems to crash with Office 2010 + Win 7 SP1 due to a null pointer
    dereference in DoVerb –> CPackage::GetContextMenu –> packager!CPackage::CreateTempFileName.

PATCHING

The patch is found in packager.dll. A MarkFileUnsae() function is introduced in
CPackage::OLE2MPlayerReadFromStream(). With the patch, the INF should trigger a prompt that
warns the user about the operation.

However, someone claims the following:

“KB2919355 (Windows 8.1 update) remove InfDefaultInstall.exe from g_lpAutoApproveEXEList in
appinfo.dll, thx cve-2014-4114 for the help” – https://twitter.com/w4kfu/status/522492861225639936

I looked at that specific KB2919355 patch, and there is no appinfo.dll in there. BUT, the claim
seems plausible becaues g_lpAutoApproveEXEList does have infDefaultInstall.exe in there:

.data:0624B054 ?g_lpAutoApproveEXEList@@3PAPBGA dd offset aCttunesvr_exe
.data:0624B054                                         ; DATA XREF: AipIsAutoApprovalEXE(ushort const *)+Eo
.data:0624B054                                         ; "cttunesvr.exe"
.data:0624B058                 dd offset aInetmgr_exe  ; "inetmgr.exe"
.data:0624B05C                 dd offset aInfdefaultinst ; "infdefaultinstall.exe"
.data:0624B060                 dd offset aMigsetup_exe ; "migsetup.exe"
.data:0624B064                 dd offset aMigwiz_exe   ; "migwiz.exe"
.data:0624B068                 dd offset aMmc_exe      ; "mmc.exe"
.data:0624B06C                 dd offset aOobe_exe     ; "oobe.exe"
.data:0624B070                 dd offset aPkgmgr_exe   ; "pkgmgr.exe"
.data:0624B074                 dd offset aProvisionshare ; "provisionshare.exe"
.data:0624B078                 dd offset aProvisionstora ; "provisionstorage.exe"
.data:0624B07C                 dd offset aSpinstall_exe ; "spinstall.exe"
.data:0624B080                 dd offset aWinsat_exe   ; "winsat.exe"

References

=== The Patch

Microsoft patched this vulnerability with MS14-060

https://technet.microsoft.com/en-us/library/security/ms14-060.aspx

The HP analysis I think isn’t 100% accurate, according to my bindiff the patch MS14-060 is adding a call “MarkFileUnsafe” to different methods available to drop files to the filesystem:

  • OLE2MplayerReadFromStream
  • OLE1SoundRecReadFromStream
  • OLE2SoundRecReadFromStream

=== Ideas to bypass patch

  • Idea 1: Obvious one, find another path where the “MarkFileUnsafe” has been forgotten. Unfortunately with static analysis I’ve not found nothing interesting.
  • Idea 2: The abused function hasn’t been killed, the droped files are just marked as unsafe… so maybe working with other file types can have some success.

The original exploit basically embeds packager objects as OLE streams, allowing:

  • To drop arbitrary files to temp => It can be done also after the patch.
  • Also use the “famous” CmdVerb = 3, which basically simulates a right click and then left click on the “alternate” option. When used on a INF file it simulates a click on the “Install” option.

So the idea here is to find a file type whose second option in the right click is interesting. For example, when I install the “Geany” Editor, windows automatically adds the “Open With Geany” option with a lot of file types. I can embedd any file of these types inside a package, then inside an OLE, and run the ppsx. The “Geany” editor is executed automatically and tries to open the file, since “Geany” isn’t marked as unsafe at all, and the editor isn’t trying to execute nothing.

The idea would be to found a filetype which can be opened through the second option of the contextual menu, and it allows to embed code (scripting)

At the moment I’ve not found other file type whose second choice in the right click menu (contextual menu) is interesting for exploitation. I’ve tried powershell, but since the file is marked as unsafe a warning arises when powershell tries to execute it directly.

(There are some reports about this idea being used in the wild with ppsx’s directly embedding an EXE, and going through “run it as an Administrator”, but in this way UAC triggers.

  • Idea 3: Try other CmdVerb’s to analyze other parts of the CmdVerb function not triggered.

General Information

Exploited in the Wild

Reported by:

Additional Info

Technical Analysis