Poppler PDF Image Display DCTStream::readScan() Code Execution Vulnerability(CVE-2017-2814)

2017-09-14T00:00:00
ID SSV:96474
Type seebug
Reporter Root
Modified 2017-09-14T00:00:00

Description

Summary

An exploitable heap overflow vulnerability exists in the image rendering functionality of Poppler-0.53.0. A specifically crafted pdf can cause an image resizing after allocation has already occurred, resulting in heap corruption which can lead to code execution. An attacker controlled PDF file can be used to trigger this vulnerability.

Tested Versions

Poppler-0.53.0

Product URLs

https://poppler.freedesktop.org/

CVSSv3 Score

7.5 - CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H

CWE

CWE-122: Heap-based Buffer Overflow

Details

Poppler is a shared library for displaying PDF files, used as middleware within different enterprise and opensource solutions alike (e.g. Gimp). It is forked off of XPDF, and is a complete implementation of the PDF ISO standard. The Poppler library, by default, uses a private implementation of reading and rendering images. There is an compilation option for libjpeg support, but the flag is not enabled by default. This private implementation contains assumptions about the JPEG file headers that can lead to heap corruption when broken. Whenever the PDF Lexer discovers an image, the DCTStream::reset() method eventually gets called to process the image headers found in the PDF. ``` void DCTStream::reset() { int i, j;

dctReset(gFalse);

if (!readHeader()) { y = height; return; } ... ```

Due to how JPEGs are stored and compressed (Discrete Cosine Transforms), an appropriate amount of space has to be allocated for the DCT decompression to occur (still in DCTStream::reset()) [0] ``` if (progressive || !interleaved) { bufWidth = ((width + mcuWidth - 1) / mcuWidth) * mcuWidth; bufHeight = ((height + mcuHeight - 1) / mcuHeight) * mcuHeight; if (bufWidth <= 0 || bufHeight <= 0 || bufWidth > INT_MAX / bufWidth / (int)sizeof(int)) { error(errSyntaxError, getPos(), "Invalid image size in DCT stream"); y = height; return; }

 (i = 0; i &lt; numComps; ++i) {   // [0]
  frameBuf[i] = (int *)gmallocn(bufWidth * bufHeight, sizeof(int));
  memset(frameBuf[i], 0, bufWidth * bufHeight * sizeof(int));
}

```

After the space has been allocated, further headers and data are read in to prepare for the DCT algorithm as such (still in DCTStream::reset()). The readScan() function [0] transforms 8x8 pixel blocks. While readHeader() [2] will read headers continuously till error or until the readScanInfo() method returns gTrue. do { restartMarker = 0xd0; restart(); readScan(); // [1] } while (readHeader()); // [2]

The main issue lies in that the width and height variables that determine the size of the allocated buffer are class variables read from a specific header inside of the readHeader() function, more specifically, either readProgressiveSOF (\xff\xc2) or readBaselineSOF (\xff\xc1). Thus, if a specially crafted PDF file can allocate a JPEG buffer and then resize the height and width after the allocation, it will cause poppler to perform DCT data transforms on internal heap memory when it tries to read the image data. (inside of DCTStream::readScan()). The code below shows the issue: ``` for (y1 = 0; y1 < height; y1 += dy1) { //orig height = 0xd9; new height = 0x10b for (x1 = 0; x1 < width; x1 += dx1) { //orig width = 0xd9; new width = 0x10c // ... for (cc = 0; cc < numComps; ++cc) { // ... h = compInfo[cc].hSample; v = compInfo[cc].vSample; horiz = mcuWidth / h;
vert = mcuHeight / v;
vSub = vert / 8;
for (y2 = 0; y2 < dy1; y2 += vert) { //dy1 == 8 for (x2 = 0; x2 < dx1; x2 += horiz) { //dx1 == 8 p1 = &frameBuf[cc][(y1+y2) * bufWidth + (x1+x2)]; // [3] for (y3 = 0, i = 0; y3 < 8; ++y3, i += 8) { data[i] = p1[0]; // [5] //... data[i+7] = p1[7]; p1 += bufWidth * vSub;

 // Ö [4]

 p1 = &frameBuf[cc][(y1+y2) * bufWidth + (x1+x2)];  
         for (y3 = 0, i = 0; y3 &lt; 8; ++y3, i += 8) {
           p1[0] = data[i];     // [5]
   //... 
           p1[7] = data[i+7];
           p1 += bufWidth * vSub;
    } // Ö

... ```

The code at [3] will cause p1 to point past the end of the allocated buffer, it will subsequently be written to at [5].

Crash Information

RAX: 0x0 RBX: 0xea RCX: 0xffffffffffffffff RDX: 0x6 RSI: 0x133de RDI: 0x133de RBP: 0x7ffe093f29e0 --&gt; 0x7ffe093f29f0 ("0000000002677ca0") RSP: 0x681ffe00 --&gt; 0x7f8fb3456598 --&gt; 0xffffffc1c748c931 RIP: 0x70000002 --&gt; 0xfc3050fc3050fc3 R8 : 0x3061633737363230 ('02677ca0') R9 : 0x6f6974707572726f ('orruptio') R10: 0x8 R11: 0x246 R12: 0x7ffe093f27f0 --&gt; 0x7ffe093f28a0 --&gt; 0x7ffe093f28c0 --&gt; 0x7f8fb04db220 ("': %s: 0x%s ***\n") R13: 0x7 R14: 0x59 ('Y') R15: 0x681fffa0 --&gt; 0xea EFLAGS: 0x246 (carry PARITY adjust ZERO sign trap INTERRUPT direction overflow) [-------------------------------------code-------------------------------------] =&gt; 0x70000002: ret 0x70000003: syscall 0x70000005: ret 0x70000006: syscall [------------------------------------stack-------------------------------------] 0000| 0x681ffe00 --&gt; 0x7f8fb3456598 --&gt; 0xffffffc1c748c931 0008| 0x681ffe08 --&gt; 0x0 0016| 0x681ffe10 --&gt; 0x0 0024| 0x681ffe18 --&gt; 0x7f8fb34530f5 --&gt; 0x1f0f66c328c48348 0032| 0x681ffe20 ("orruptio") 0040| 0x681ffe28 --&gt; 0x70000000 --&gt; 0x50fc3050fc3050f 0048| 0x681ffe30 --&gt; 0x0 0056| 0x681ffe38 --&gt; 0x0 [------------------------------------------------------------------------------] Legend: code, data, rodata, value Stopped reason: SIGABRT

Timeline

  • 2017-05-16 - Vendor Disclosure
  • 2017-07-07 - Public Release

CREDIT

  • Discovered by Marcin Noga and Lilith Wyatt of Cisco Talos.