=================================================================

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/