Talos Vulnerability Report

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;

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

Timeline

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