On exploiting MS08-021 (CVE-2008-1083)

So I managed to create a simple proof of concept for the vulnerability, thanks to the 010 Editor (which is just plain hawt) and a WMF template. Anyhow, here is what it looks like:

We obviously need cjBitmapBitSize to return a value large enough to trigger the arithmetic overflow, which means we need something around 0xFFFFFF00. The value I aimed for and ended up with was 0xFFFFFFE0, although there were a few different options we could have used. This was more annoying than anything since we had to deal with the arithmetic in cjBitmapBitSize, which remember looks like this:

(((((bcPlanes * bcBitCount) * bcWidth) + 0×1F) & 0xFFFFFFE0) / 8) * bcHeight)

Now reading the documentation, the value of bcBitCount is going to be one of the values from the BitCount enumeration. I’m not going to post the entire enum, but I chose to use BI_BITCOUNT_2 (0×4). You can Google for the definition and explanation of the enum, but for now we’ll just assume bcBitCount == 0×00000004.

The next problem we have is that pesky division operation, but we can easily counter that by just setting bcHeight to 8. This is just an easier way to deal with it, we can easily modify other values to get the value we want. The addition and AND operation aren’t all that much of an importance here, just make sure that whatever values you choose don’t cause an overflow when 0×1f is added. So that said, what about bcPlanes?

The WMF documentation states that bcPlanes MUST be set to 0×1. Fortunately for us, this isn’t enforced or checked anywhere, so we can set it to any value we want. So here are the values I used:

bcPlanes = 0xe3c4
bcHeight = 0×8
bcWidth = 0×8fde
bcBitCount = 0×4

So knowing all of that, we are going to use a META_DIBCREATEPATTERNBRUSH (0×0142) record to actually get those values passed into the function. The record looks something like this:

DWORD RecordSize
WORD RecordFunction
WORD Style
WORD ColorUsage
DIB Object (variable length)

The RecordSize and RecordFunction values are straightforward. The RecordSize value is going to be the size of the entire record in WORDs and RecordFunction is going to be 0×0142 for META_DIBCREATEPATTERNBRUSH.

The values for Style and ColorUsage are tied in with one another, we obviously set Style to BS_DIBPATTERNPT (0×0006). I set ColorUsage to DIB_RGB_COLORS (0×0000), which indicates that the ColorTable in the DIB object is going to contain RGBQuad objects.

Now for the DIB object. The object itself looks like this:

DIBHeaderInfo (either BitmapCoreHeader or BitmapInfoHeader)
ColorTable
aData

All the members are variable length.

We know that DIBHeaderInfo is going to be a BitmapCoreHeader object, which looks like this:

DWORD HeaderSize
WORD Width
WORD Height
WORD Planes
WORD BitCount

Since this is a BitmapCoreHeader object, HeaderSize is going to be 0×0000000C. The reasoning behind this is shown in my previous post and in the documentation. We then set the remaining values to the values I mentioned earlier.

The end result is that an inline memory copy occurs using the size value returned from cjBitmapBitsSize as a counter, which obviously means more memory is going to be copied than we have allocated space for. The values from aData are what is written into our buffer. If you follow my path, you’ll want to have at least 16 DWORDs with the lower 2 bytes clear following after BitCount in the ColorTable. Everything after that is aData and will be smeared all over the heap. Don’t forget to update nSize and RecordSize as you make changes, otherwise it won’t load.

That is about the extent of what I’ve done up until now. I managed to overwrite a function pointer once or twice, but I haven’t spent that much time trying to get a reliable exploit. It is definitely possible, so we’ll see if I manage to find some time to do it :)