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