Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=849

As already discussed in a number of reports in this tracker (#285, #286, #287, #288, #289, #292), VMware Workstation (current version 12.1.1 build-3770994) ships with a feature called "Virtual Printers", which enables the virtualized operating systems to access printers installed on the Host. Inside the VM, the communication takes place through a COM1 device, and the incoming data is handled by a dedicated "vprintproxy.exe" process on the Host, as launched by the "vmware-vmx.exe" service. Administrative privileges are not required to access COM1 in the guest, at least on Windows.

The vprintproxy.exe is a significant attack surface for potential VM escapes. Due to its nature, the application implements support for a variety of complex protocols and file formats, such as the printing protocol, EMFSPOOL format, and further embedded EMFs, fonts, images etc. This report addresses a bug in the handling of TrueType fonts embedded in EMFSPOOL, as implemented in the TPView.DLL library extensively used by vprintproxy.exe.

The version of the TPView.DLL file referenced in this report is 9.4.1045.1 (md5sum b6211e8b5c2883fa16231b0a6bf014f3).

TrueType fonts can be embedded in EMFSPOOL files via EMRI_ENGINE_FONT records. When such a record is encountered while processing the printing request data, some complex logic is executed to load the font into the program's internal structures. For reasons which are not fully clear to me, one of the operations is to copy the contents of the CMAP table into the NAME table in memory - or, if the latter is larger than the former, create a completely new NAME table with CMAP's data. This is generally implemented in a function located at address 0x1005C230, and the high-level logic is as follows:

--- cut ---
  CMAP = FindCmapTableHeader();
  CMAP_size = ExtractSize(CMAP);
  CMAP_body = ExtractBody(CMAP);

  NAME = FindNameTableHeader();
  if (NAME) {
    NAME_size = ExtractSize(NAME);
    NAME_body = ExtractBody(NAME);

    SetTableSize(NAME, CMAP_size);

    memset(NAME_body, 0, NAME_size);

    if (CMAP_size > NAME_size) {
      SetTableOffset(NAME, font_size);
      
      font_data = realloc(font_size + CMAP_size);
      memset(&font_data[font_size], 0, CMAP_size);
      memcpy(&font_data[font_size], CMAP_body, CMAP_size);
    } else {
      memcpy(NAME_body, CMAP_body, CMAP_size);
    }
  }
--- cut ---

As you can see, the function doesn't perform any bounds checking of the values (offsets, sizes) loaded from table headers. Some of the fields have already been verified before and are guaranteed to be valid at this point of execution, but some of them (such as CMAP_body or NAME_size) are still fully controlled. While controlling the pointer to the CMAP section data (relative to the start of the font buffer) may be useful, being able to cheat about the NAME table size enables an attacker to cause a much more dangerous memory corruption on the heap.

For example, if we set the NAME size to an enormous value (e.g. 0xAAAAAAAA), we will encounter an immediate crash in the memset() function, as shown below:

--- cut ---
(22f0.26ac): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Program Files (x86)\Common Files\ThinPrint\TPView.dll - 
eax=01555540 ebx=00000000 ecx=215cefc0 edx=00000026 esi=215b87d4 edi=aaaaaaaa
eip=68102056 esp=2247f298 ebp=2247f2e8 iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202
TPView!TPRenderW+0x1547f6:
68102056 660f7f4140      movdqa  xmmword ptr [ecx+40h],xmm0 ds:002b:215cf000=????????????????????????????????
--- cut ---

If the NAME table size is increased by a smaller degree, such that the memset() call doesn't hit unmapped page boundary, the code may successfully finish the call and proceed to copying the contents of the CMAP section into the small NAME memory area, which would finally result in a typical heap-based buffer overflow condition with controlled length and data.

Attached is a Proof of Concept Python script, which connects to the COM1 serial port, and sends an EMFSPOOL structure containing a font file with the NAME table length set to 0xAAAAAAAA. When launched in a guest system, it should trigger the crash shown above in the vprintproxy.exe process on the host. The script is a slightly reworked version of Kostya's original exploit.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40398.zip