Recipe 2 - CVE-2010-0033 PowerPoint Viewer

We will be exploiting CVE-2010-0033 in this recipe.  The advisory describes a stack based overflow in PowerPoint Viewer's TextByteAtom record.

There are public exploits available for this.  I felt it was good to show a SEH based exploit, since the last recipe was a direct EIP overwrite.

This recipe was tested on Windows Vista 32 bit.

You will need the following applications/tools to complete this recipe:

• PowerPoint Viewer (Version 11.0.8164.0, Office 2003) 
• PowerPoint (For making slides.)
• Immunity Debugger (1.8 was used)
• pvefindaddr (Peter Van Eeckhoutte's Immunity Debugger plugin)
• Metasploit ( For payload generation)
• Notepad++ (You can use any text editor, I just prefer this one)
• HxD (You can use any Hex Editor, this is just the one I use)

Warning: This tutorial is for educational purposes only. 

To start off make a PowerPoint presentation with a single text box and fill it with A’s.  This will help identify where in the file our input is. Save the PowerPoint and get ready for a little research.

PowerPoint

 The advisory states that the error occurs with the TextBytesAtom record.  Microsoft does a good job with documenting just about everything in their MSDN.  So doing a search for TextBytesAtom record on MSDN brings us to this page.

TextBytesAtom Definition

 

The page describes the structure of a TextBytesAtom header in PowerPoint, and we see that for a TextBytesAtom, rh.recType must be set to RT_TextBytesAtom.  Following the record type link here shows that the value of  RT_TextBytesAtom is 0x0FA8. 

TextBytesAtom Record Type Value

Now we know what the record value is to search for, open the PowerPoint we created in a hex editor, and search for A8 0F (little endian remember).

TextBytesAtom Record

 Now going back to our MSDN reference, look at the definition of a RecordHeader here.  

RecordHeader Definition

We see that after the recType (record type) is defined we have recLen, which is a 4 byte unsigned integer that specifies the length of the record data. Our length is set to 0x000000B0, so lets go ahead and make that the largest value possible, 0xFFFFFFFF. After saving the file, try to open it in PowerPoint Viewer.

Exception

 We get an exception and we can see the offset is set to 41414141, so it is reading into our slide.  Lets open Immunity Debugger, attach to the Viewer, and try to open the file again. We get an access violation and the debugger pauses.  EIP is not overwritten,  so there is an exception handler stopping us.  In the debugger go to view -> SEH chain, notice how it is overwritten with 41414141, the characters in our PowerPoint slide.   You can also right click on the address and click on “Follow address in stack”, there you will notice that the “SE handler” and “pointer to next SEH record” is overwritten with A’s. 

SEH Chain

Examining in Stack

Now generate a random pattern to place in the slide instead of A’s so we can get the offsets of where everything is happening.  Generate the pattern using “!pvefindaddr pattern_create 1000” in the debugger.  This will save the pattern under mspattern.txt in your debugger’s installation directory.  Copy the pattern into a new PowerPoint, open it in a hex editor and make the length 0xFFFFFFFF again on the 0xF0A8 (TextBytesAtom) record.

Pattern Slide

 Save the file, open PowerPoint Viewer and attach to it with the debugger. Open the file, when the exception occurs view the SEH records again and follow the address in the stack.  Make a note of the two values in the next SEH pointer and the current SE handler.  

Pattern Location

 With a typical SEH exploit our payload will look like this:

SEH Based Exploit

 The SEH record gets overwritten with a pointer to POP POP RET.  Just as with direct EIP overwrites, this pointer will ideally come from a module that comes with the program so we will have a more reliable exploit.  This will land us at returning what is in the next SEH pointer.  This pointer gets overwritten with assembly code to jump 6 bytes (\xEB\x06) back down into our shellcode or NOP’s. You just need to verify there are no null bytes or anything breaking up your shellcode.  If there is, then you will have to jump further down the stack. 

Now we know what needs to be done we can search for a suitable pointer to POP POP RET.  In the debugger, go to View ->  Executable modules. Notice gdiplus.dll is loaded from the office directory.  Double click on it, this should bring the code up in the CPU window.  Press CTRL + S  to search for a sequence of commands, and enter in the following:

Searching for Suitable Pointer

Found

We have a hit at 0x398334A3.  We will take it and place it in our PowerPoint file in place of the SE handler. We will also put our jump code in place of the next SEH pointer, add a couple NOP’s to make it 4 bytes, and some more NOP's with a message box shellcode after the SE handler.  You can generate the payload using “./msfpayload windows/messagebox TITLE="Testing" TEXT="Hello World" R”.

Return to the TextBytesAtom header in your file, and search for the pattern that occupied the next SEH pointer (Ae4A, starting after 132 bytes in the pattern).  Our payload will start there.

Beginning of Payload

 The end result should look similar to this:

Final PowerPoint

 Now save the file and open it in PowerPoint Viewer.

Done!

 If you want to see how it works more closely you can attach to the debugger and set a breakpoint at the SE handler and next SEH record pointer.  Then just step through execution.  Also remember you can code breakpoints into your payload by using "\xCC"  this will also stop execution when hit.  This can be usefull if you want to stop somewhere in your payload to make sure it is getting hit.