MSIE 11 MSHTML CPaste­Command::Convert­Bitmapto­Png heap-based buffer overflow

(MS14-056, CVE-2014-4138)

Synopsis

A specially crafted web-page can trigger an out-of-bounds write in Microsoft Internet Explorer 11. Code that handles pasting images from the clipboard uses an incorrect buffer length, which allows writing beyond the boundaries of a heap-based buffer. An attacker able to trigger this vulnerability can execute arbitrary code.

Known affected software, attack vectors and potential mitigations

• Microsoft Internet Explorer 11.0.9600.16521

  An attacker would need to get a target user to open a specially crafted web-page. In order to trigger the issue, the web-page needs to either programmatically copy/paste an image using Javascript or get the user to do this (for instance by tricking the user into typing keyboard shortcuts such as CTRL+C/CTRL+V) . By default, MSIE prompts the user to allow or disallow programmatically copy/pasting the first time a website tries to do this, so user-interaction is normally required in such cases. Disabling the Allow Programmatic clipboard access setting in Internet Options -> Security Settings -> [Choose a zone] -> Scripting should prevent websites from programmatically copy/pasting an image. Disabling execution of scripts on web-pages altogether will have the same effect. Please note that neither option prevents a website from social engineering the user into typing a keyboard shortcut to copy/paste the image.

Details

When an image is pasted in MSHTML, it gets converted from BMP format to PNG. This is done in the MSHTML!CPaste­Command::Convert­Bitmapto­Png function. This function incorrectly uses the size of the original BMP image to allocate memory for storing the converted PNG image. The PNG image will be smaller than the BMP under most circumstances, but if a specially crafted image leads to the original BMP image being smaller than the converted PNG, the function will write PNG data beyond the bounds of the allocated memory.

Here is some pseudo code that was created by reverse engineering the CPaste­Command::Convert­Bitmapto­Png function, which shows the vulnerability:

Convert­Bitmapto­Png(
  [IN] VOID* po­Bitmap,  UINT u­Bitmap­Size,
  [OUT] VOID** ppo­Png­Image, UINT* pu­Png­Image­Size
) {
  // Convert a BMP formatted image to a PNG formatted image.
  CMem­Stm* po­CMem­Stm;
  IWICStream* po­Wic­Bitmap;
  STATSTG o­Stat­Stg;
  TSmart­Array<unsigned char> po­Png­Image;
  UINT u­Read­Size;
  // Create a CMem­Stm for the PNG image.
  Create­Stream­On­HGlobal(NULL, True, po­CMem­Stm);
  // Create an IWICStream from the BMP image.
  Initialize­From­Memory(po­Bit­Map, u­Bitmap­Size,
      &GUID_­Container­Format­Bmp, &po­Wic­Bitmap)));
  // Write BMP image in IWICStream to PNG image in CMem­Stm
  Write­Wic­Bitmap­To­Stream(po­Wic­Bitmap, &GUID_­Container­Format­Png, po­CMem­Stm);
  // Get size of PNG image in CMem­Stm and save it to the output variable.
  o­CMem­Stm->Stat(&o­Stat­Stg, 0);
  *pu­Png­Image­Size = o­Stat­Stg.cb­Size.Low­Part;
  // Allocate memory for the PNG
  po­Png­Image->New(u­Bitmap­Size);
  // Go to start of PNG image in CMem­Stm
  po­CMem­Stm->Seek(0, STREAM_­SEEK_­SET, NULL, &p­Position­Low);
  // Read PNG image in CMem­Stm to allocated memory.
  po­CMem­Stm->Read(po­Png­Image, *pu­Png­Image­Size, &u­Read­Size);
  // Save location of allocated memory with PNG image to output variable.
  *ppo­Png­Image = po­Png­Image;
}

Notes:

• The code uses the wrong size to allocate memory in po­Png­Image->New(u­Bitmap­Size);. Changing this line of code to po­Png­Image->New(*pu­Png­Image­Size); should address the issue.
• The PNG image is written to the allocated memory in po­CMem­Stm->Read(po­Png­Image, *pu­Png­Image­Size, &u­Read­Size);. This is where the code can potentially write beyond the boundaries of the allocated memory if u­Bitmap­Size is smaller than *pu­Png­Image­Size.

Below are my notes from reversing the code for your viewing pleasure. There are a few flaws/omissions in the parts that are not directly relevant to the bug, as I did not attempt to finish all the details after I figured out enough to determine root cause, exploitability and attack vectors.

Exploit

An attacker looking to exploit this issue will commonly attempt to get the memory allocated to store the PNG image in a location that is followed by a pre-allocated memory block that contains information the attacker would like to modify. Using the buffer overflow, the attacker can overwrite this pre-allocated memory block with attacker controlled data. Depending on the type of the pre-allocated memory, this could allow the attacker to read or modify arbitrary information within the process and take control of execution flow. No attempt was made to create a Proof-of-Concept that shows this level of control.

Time-line

• 8 May 2014: This vulnerability was submitted to ZDI.
• 9 June 2014: This vulnerability was acquired by ZDI.
• 23 June 2014: This vulnerability was disclosed to Microsoft by ZDI.
• 14 October 2014: This vulnerability was address by Microsoft in MS14-056.
• 21 December 2016: Details of this vulnerability are released.