Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=850
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 multitude of bugs in the handling of JPEG2000 images embedded in a custom record 0x8000 inside EMF, 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).
The CTPViewDoc::WriteEMF function (adddress 0x100518F0) iterates over all EMF records found in the EMFSPOOL structure sent over COM1 for printing, and performs special handling of some of them. One such record is a custom type 0x8000, expected to store a JPEG2000 image wrapped in a structure similar to that of a EMF_STRETCHDIBITS record. The handler at 0x100516A0, and more specifically a further nested function at 0x1003C000 performs complete parsing of the J2K format, opening up the potential for software vulnerabilities. An example of a bug in that code area discovered in the past is a stack-based buffer overflow in the processing of record 0xff5c (Quantization Default), reported by Kostya Kortchinsky in bug #287.
Since the source code of the JPEG2000 implementation used by VMware is not publicly available, and the file format is sufficiently complex that a manual audit sounds like a dire and very ineffective option to find bugs, I have set up a fuzzing session to automate the process. As a result, with the PageHeap option enabled in Application Verifier for vprintproxy.exe, the fuzzer has managed to trigger hundreds of crashes, in a total of 39 unique code locations. Below is a list of different instructions which generated a crash, with a brief description of the underlying reason.
+----------------------------+-----------------------------------------------+
| Instruction | Reason |
+----------------------------+-----------------------------------------------+
| add [eax+edx*4], edi | Heap buffer overflow |
| cmp [eax+0x440], ebx | Heap out-of-bounds read |
| cmp [eax+0x8], esi | Heap out-of-bounds read |
| cmp [edi+0x70], ebx | Heap out-of-bounds read |
| cmp [edi], edx | Heap out-of-bounds read |
| cmp dword [eax+ebx*4], 0x0 | Heap out-of-bounds read |
| cmp dword [esi+eax*4], 0x0 | Heap out-of-bounds read |
| div dword [ebp-0x24] | Division by zero |
| div dword [ebp-0x28] | Division by zero |
| fld dword [edi] | NULL pointer dereference |
| idiv ebx | Division by zero |
| idiv edi | Division by zero |
| imul ebx, [edx+eax+0x468] | Heap out-of-bounds read |
| mov [eax-0x4], edx | Heap buffer overflow |
| mov [ebx+edx*8], eax | Heap buffer overflow |
| mov [ecx+edx], eax | Heap buffer overflow |
| mov al, [esi] | Heap out-of-bounds read |
| mov bx, [eax] | NULL pointer dereference |
| mov eax, [ecx] | NULL pointer dereference |
| mov eax, [edi+ecx+0x7c] | Heap out-of-bounds read |
| mov eax, [edx+0x7c] | Heap out-of-bounds read |
| movdqa [edi], xmm0 | Heap buffer overflow |
| movq mm0, [eax] | NULL pointer dereference |
| movq mm1, [ebx] | NULL pointer dereference |
| movq mm2, [edx] | NULL pointer dereference |
| movzx eax, byte [ecx-0x1] | Heap out-of-bounds read |
| movzx eax, byte [edx-0x1] | Heap out-of-bounds read |
| movzx ebx, byte [eax+ecx] | Heap out-of-bounds read |
| movzx ecx, byte [esi+0x1] | Heap out-of-bounds read |
| movzx ecx, byte [esi] | Heap out-of-bounds read |
| movzx edi, word [ecx] | NULL pointer dereference |
| movzx esi, word [edx] | NULL pointer dereference |
| push dword [ebp-0x8] | Stack overflow (deep / infinite recursion) |
| push ebp | Stack overflow (deep / infinite recursion) |
| push ebx | Stack overflow (deep / infinite recursion) |
| push ecx | Stack overflow (deep / infinite recursion) |
| push edi | Stack overflow (deep / infinite recursion) |
| push esi | Stack overflow (deep / infinite recursion) |
| rep movsd | Heap buffer overflow, Heap out-of-bounds read |
+----------------------------+-----------------------------------------------+
Considering the volume of the crashes, I don't have the resources to investigate the root cause of each of them, and potentially deduplicate the list even further. My gut feeling is that the entirety of the crashes may represent 10 or more different bugs in the code.
Attached is a Python script which can be used to test each particular JPEG2000 sample: it is responsible for wrapping it in the corresponding EMF + EMFSPOOL structures and sending to the COM1 serial port on the guest system. It is a reworked version of Kostya's original exploit from bug #287. In the same ZIP archive, you can also find up to three samples per each crash site listed above.
It was empirically confirmed that some of the heap corruptions can be leveraged to achieve arbitrary code execution, as when the Page Heap mechanism was disabled, the process would occasionally crash at invalid EIP or a CALL instruction referencing invalid memory addresses (vtables).
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/40399.zip
