Ms08-046

Hello everyone!

Today I decided to do something ambitious and I took a look at the MS08-046 which describes the bug in Microsoft Color Management System (MSCMS)

I diffed the vulnerable and not vulnerable mscms.dll and found out that the problem lies in OpenColorProfileW function here:

[XPSP2 mscms.dll 5.1.2600.2709]

Code:

---

.text:73B339F5                push    esi            ; dwBytes
.text:73B339F6                mov    [ebp+pdwSize], esi
.text:73B339F9                call    sub_73B31FB1
.text:73B339FE                mov    edi, eax  <---- eax = heap allocated block with GlobalAlloc
.text:73B33A00                test    edi, edi
.text:73B33A02                mov    [ebp+lpString1], edi
.text:73B33A05                jz      short loc_73B339EE
.text:73B33A07                lea    eax, [ebp+pdwSize]
.text:73B33A0A                push    eax            ; pdwSize
.text:73B33A0B                push    edi            ; pBuffer
.text:73B33A0C                push    0              ; pMachineName
.text:73B33A0E                call    GetColorDirectoryW
.text:73B33A13                push    offset asc_73B420B4 ; "\\"
.text:73B33A18                push    edi            ; lpString1
.text:73B33A19                mov    edi, ds:lstrcatW
.text:73B33A1F                call    edi ; lstrcatW
.text:73B33A21                push    dword ptr [ebx+0Ch] ; lpString2
.text:73B33A24                push    [ebp+lpString1] ; lpString1
.text:73B33A27                call    edi ; lstrcatW  <---- here the BOF takes place
.text:73B33A29                push    dword ptr [ebx+0Ch] ; pMem
.text:73B33A2C                call    sub_73B31C29
.text:73B33A31                mov    eax, [ebp+lpString1]
.text:73B33A34                mov    [ebx+0Ch], eax
.text:73B33A37                mov    [ebx+10h], esi
.text:73B33A3A                jmp    loc_73B31ED0

---

That's as far as I got. I was curious if anyone here is experienced with heap overflows as stack overflows are pretty easy to exploit comparing with the heap (without GuardStack of course). I'm familiar that the heap looks different in SP1 and SP2, so I just ask about SP2. I've read several documents about it, but it seems to me that for it to succeed very special conditions must be met.

I have also one question. It's said that 64-bit processors have this kind of heap protection that don't allow to run any code from the heap. Does it also apply if someone is using 32-bit OS?

Regards,
blackd0t