Well, you should upgrade SketchUp to the last version (2 bugs here). ================================================================= ================================================================= Title: Sketchup MAC Pict Material Palette Stack Corruption Product: Trimble SketchUp Advisory ID: BINA-20130521A CVE ID: CVE-2013-3664 Class: Boundary Error Condition (Buffer Overflow) Vulnerability class: Client side/ file format Permalink: http://binamuse.com/advisories/BINA-20130521A.txt Vendor notified on: 2013-04-18 Patch/Fix Released: 2013-05-21 Advisory Published: 2013-05-23 Vulnerability Description: SketchUp is a 3D modeling program marketed by Trimble Navigation Limited and designed for architectural, civil, and mechanical engineers as well as filmmakers, game developers, and related professions. SketchUp fails to validate the input when parsing an embedded MACPict texture. Arbitrary code execution is proved possible after a malicious texture or thumbnail or background image triggers a stack overflow. The issue can also be triggered when Windows Explorer reads the embedded thumbnail in a .skp file. Vulnerable Packages: SketchUp 8 - Maintenance 5 - Win 8.0.16846 Mac 8.0.16845 SketchUp 8 - Maintenance 4 - Win 8.0.15158 Mac 8.0.15157 SketchUp 8 - Maintenance 3 SketchUp 8 - Maintenance 2 SketchUp 8 - Maintenance 1 SketchUp 8 SketchUp 7.1 - Maintenance 2 SketchUp 7.1 - Maintenance 1 SketchUp 7.1 SketchUp 7 - Maintenance 1 SketchUp Pro 6 - Maintenance 6 Not Vulnerable Packages: Sketchup 2013 Solution/Vendor Information/Workaround: Upgrade to Sketchup 2013 URL: http://www.sketchup.com/products/sketchup-pro/new-in-2013 For other version of the software contact vendor for an appropriate fix. Credits: This vulnerability was found by Juan Pablo "El Lagarto" De Francesco of the Binamuse Vulnerability Research Team, http://binamuse.com Technical Description: The native SketchUp fileformat can handle textured 3D content. Sketchup can create realistic materials taken from image files such as .jpg pictures taken with a digital camera. A number of this images can be embedded into the main .skp file and loaded every time the 3D scene is open. The bug is triggered when SketchUp loads the color palette table of a MAC Pict material (or embedded image). A MAC Pict file can hold palettes of up to 64k colors. It is encoded so the number of colors to read from the file is the first 16bit unsigned value of the encoded palette. '>H' numColors Then it follows a list of up to numColors palette entries. [ '>H' color index 'BBB' RGB ] * numColors Each entry is a pair of index and RGB color and the entries can be put in any order. The only constraint is that each index must be less or equal than numColor. SketchUp reads this potentially 64k entries length table in a 256 entries length stack buffer. Thus, is fair to say that an almost arbitrary offset of the stack can be written with an almost arbitrary value. Playing with the stacked local values of the calling functions it is possible to capture the execution flow and execute arbitrary code. Exploitation of the above problem will lead to the execution of arbitrary code on the client machine with the privileges of the user running the Sketchup. REFERENCES: http://blog.binamuse.com/2013/05/multiple-vulnerabilities-on-sketchup.html http://binamuse.com/advisories/BINA-20130521B.txt DISCLAIMER: The content of this advisory are copyright (c) 2013 Binamuse Inc. and may be distributed freely provided that no fee is charged for this distribution and proper credit is given. ================================================================= ================================================================= Title: Sketchup BMP Material RLE4 Heap Overflow Product: Trimble SketchUp Advisory ID: BINA-20130521B CVE ID: CVE-2013-3664 Class: Boundary Error Condition (Buffer Overflow) Vulnerability class: Client side/ file format Permalink: http://binamuse.com/advisories/BINA-20130521B.txt Vendor notified on: 2013-04-18 Patch/Fix Released: 2013-05-21 Advisory Published: 2013-05-23 Vulnerability Description: SketchUp is a 3D modeling program marketed by Trimble Navigation Limited and designed for architectural, civil, and mechanical engineers as well as filmmakers, game developers, and related professions. SketchUp fails to validate the input when parsing an embedded BMP RLE4 compressed texture. Arbitrary code execution is proved possible after a malicious texture or thumbnail or background image triggers a heap overflow. The issue can also be triggered when Windows Explorer reads the embedded thumbnail in a .skp file. Vulnerable Packages: SketchUp 8 - Maintenance 5 - Win 8.0.16846 Mac 8.0.16845 SketchUp 8 - Maintenance 4 - Win 8.0.15158 Mac 8.0.15157 SketchUp 8 - Maintenance 3 SketchUp 8 - Maintenance 2 SketchUp 8 - Maintenance 1 SketchUp 8 SketchUp 7.1 - Maintenance 2 SketchUp 7.1 - Maintenance 1 SketchUp 7.1 SketchUp 7 - Maintenance 1 SketchUp Pro 6 - Maintenance 6 Not Vulnerable Packages: Sketchup 2013 Solution/Vendor Information/Workaround: Upgrade to Sketchup 2013 URL: http://www.sketchup.com/products/sketchup-pro/new-in-2013 Credits: This vulnerability was found by Juan "Lagarto" De Francesco of the Binamuse Vulnerability Research Team, http://binamuse.com Technical Description: The native SketchUp fileformat can handle textured 3D content. Sketchup can create realistic materials taken from image files such as .jpg pictures taken with a digital camera. A number of this images can be embedded into the main .skp file and loaded every time the 3D scene is open. The bug is triggered when SketchUp loads BMP material with RLE 4 compression. The code parsing BMP/RLE4 images seem to be taken from http://www.paintlib.de/ paintlib/. The problematic function is "decodeRLE4" at plbmpdec.cpp, and looks like this: void PLBmpDecoder::decodeRLE4 ( PLDataSource * pDataSrc, PLBmpBase * pBmp ) // Decodes a compressed 16-color-bitmap. { int y; // Current row PLBYTE * pSrc; PLBYTE * pDest; // Current destination. int XSize = pBmp->GetWidth(); // Width of bitmap in pixels. PLBYTE SrcByte; // Source byte cache. PLBYTE RunLength; // Length of current run. bool bOdd; // true if current run has odd length. bool bEOL; // true if end of line reached. bool bEOF=false; // true if end of file reached. PLBYTE * pLineBuf; // Current line as uncompressed nibbles. PLBYTE * pBuf; // Current position in pLineBuf. PLBYTE ** pLineArray = pBmp->GetLineArray(); // Pointers to dest. lines. Trace (2, "Decoding RLE4-compressed bitmap. "); // Allocate enough memory for DWORD alignment in original 4 bpp // bitmap. pLineBuf = new PLBYTE [XSize*4+28]; for (y=0; y<pBmp->GetHeight() && !bEOF; y++) { // For each line... pBuf = pLineBuf; bEOL=false; while (!bEOL) { // For each packet do pSrc = pDataSrc->Read1Byte(); RunLength = *pSrc; if (RunLength==0) { // Literal or escape. pSrc = pDataSrc->Read1Byte(); RunLength = *pSrc; switch (RunLength) { case 0: // End of line escape bEOL = true; break; case 1: // End of file escape bEOF = true; bEOL = true; break; case 2: // Delta escape. // I have never seen a file using this. delete [] pLineBuf; raiseError (PL_ERRFORMAT_NOT_SUPPORTED, "Encountered delta escape."); break; default: // Literal packet bOdd = (RunLength & 1); RunLength /= 2; // Convert pixels to bytes. for (int i=0; i<RunLength; i++) { // For each source byte... pSrc = pDataSrc->Read1Byte(); decode2Nibbles (pBuf, *pSrc); pBuf += 2; } if (bOdd) { // Odd length packet -> one nibble left over pSrc = pDataSrc->Read1Byte(); *pBuf = (*(pSrc))>>4; pBuf++; } // Word alignment at end of literal packet. if ((RunLength + bOdd) & 1) pDataSrc->Skip(1); } } else { // Encoded packet: // RunLength 4 bpp pixels with 2 alternating // values. pSrc = pDataSrc->Read1Byte(); SrcByte = *pSrc; for (int i=0; i<RunLength/2; i++) { decode2Nibbles (pBuf, SrcByte); pBuf += 2; } if (RunLength & 1) { *pBuf = (*(pSrc))>>4; pBuf++; } } } pDest = pLineArray[pBmp->GetHeight()-y-1]; memcpy (pDest, pLineBuf, XSize); } delete [] pLineBuf; } Note that the for-loop inside the 'Encoded packet' branch decode/copy two nibbles to pBuf every time, executing this RunLength/2 times. And because there is no check about the pBuf's length before advancing the pointer two positions, a heap overflow (pBuf based) may arise. The pBuf is initialized to pLineBuf wich is a fresh allocated buffer of size XSize*4+28, being XSize the BMP's width (controlled value). So we can allocate almost any buffer size and then write and overflow it with words like 0x0X0Y (X,Y controlled nibble values). Exploitation of the above problem will lead to the execution of arbitrary code on the client machine with the privileges of the user running the Sketchup. REFERENCES: http://blog.binamuse.com/2013/05/multiple-vulnerabilities-on-sketchup.html http://binamuse.com/advisories/BINA-20130521A.txt DISCLAIMER: The content of this advisory are copyright (c) 2013 Binamuse Inc. and may be distributed freely provided that no fee is charged for this distribution and proper credit is given. f/
