MS13-068: A difficult-to-exploit double free in Outlook

MS13-068 addresses a memory corruption vulnerability accessible by simply previewing a message in the Outlook Preview Pane. As such, we’ve rated this security vulnerability as Critical and we encourage customers to deploy the security update. However, in this case, we believe this particular vulnerability will be difficult to exploit for code execution. In fact, we’re not certain that the issue is exploitable at all but out of an abundance of caution and because attack technology improves over time, we are issuing the security update today. In this blog post, we’d like to share more information about the vulnerability and the different options an attacker might otherwise have to exploit this class of vulnerability.

Root cause of the vulnerability

S/MIME allows nesting of signed messages. When encountering a message with a certain configuration of nested S/MIME certificates, Outlook crashes due to freeing a previously freed class instance pointed to by pPrivBody:

HRESULT CSMime::SMIMEINFOToOptions(
   IMimeMessageTree * const pTree,
   const SMIMEINFO *  psi,
   HBODY              hBody)
{
   CMessageBody *      pPrivBody = NULL;

//...
   for(iLayer = 0, psldLoop = psi->psldLayers; psldLoop != NULL;
       psldLoop = psldLoop->m_psldInner, iLayer++) {

//...
           pPrivBody->Release();  <strong><span style="background-color: #ff0000;">// Free here</span></strong>
//...
    }

// ...

   if (pPrivBody != NULL) pPrivBody->Release(); <strong><span style="background-color: #ff0000;">// Double free</span></strong>
   return hr;
}

Exploitability for remote code execution

There are several known conditions that could enable a double free vulnerability to be likely exploitable. The first condition involves a heap allocator adding a memory chunk to free list on the first free and this memory chunk not being used and not coalesced until the second free. A later heap allocator could then use this memory chuck in an allocation request. Regarding this particular vulnerability in Outlook, this condition is not always met because the freed heap block can be reused between the two frees according to the code logic.

There is also a second condition for a double free to be exploitable for code execution. That involves an attacker being able to write what he wants where he wants (a.k.a, “write-what-where”). However, that is not the case with MS13-068. Here’s a typical crashing instruction when the Outlook vulnerability is triggered:

eax=00000000
inc     dword ptr [eax+14h]  ds:0023:00000014=????????

As we can see it does create a write access situation. However, it appears that “what” and “where” parts are far from attacker-controllable as eax is not under attacker’s direct control and the instruction merely increments the value at eax+0x14.

Gathering these described above and other data we have, we feel that it is unlikely to be exploited in near term due to difficulty in building a reliable exploit.

- Jinwook Shin, MSRC Engineering