bugtraq - Re: Magic iso heap over flow <Help>

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date: 23 May 2007 04:49:32 -0000
From: v9@...ehalo.us
To: bugtraq@...urityfocus.com
Subject: Re: Magic iso heap over flow <Help>

I actually looked into this when you posted this on milw0rm.  I was able to get it to run arbitrary code, however it was so unreliable it wasn't worth me posting... however, it was informative.

you have control of several registers, however it's eax and edx(not ecx) that are most interesting... the next instructions that get called(and fault magiciso) are:

MOV DWORD PTR DS:[EDX],EAX
MOV DWORD PTR DS:[EAX+4],EDX

...now, with that you can overwrite any 4byte area in memory with anything you want.  the problem is you can't use null bytes(which is where the shellcode and the current SEH handler is(non-PEB)) in this situation. (and the 2nd MOV can trigger an exception, which you will want to overwrite the handler of)

you can possibly use other methods, like you mentioned(although i didnt try for this situation), but i chose to write SEH handler for that block (if you trigger it with a bunch of x's it will show up right under it in ollydbg)

step 1 for making the 0x00?????? (EDX) nullbyte:
you can just so happen to happen to overwrite this buffer with full control until the end of the buffer.  so, when most (C) functions write to a buffer they will cap it with an 0x00 on the end, i just used that.  so the overflow has to be an EXACT size for that to work.

step 2 for making the 0x00?????? (EAX) nullbyte:
once i had control of where i was writing EAX to (EDX), i had to figure out a way to make another nullbyte as that is where the shellcode was located.  to do this i came up with overwriting the SEH handler off-by-one, overwriting a single throw-away byte into another memory address(that would never be used), and leaving the original null-byte that was already there.

the downside to this is there is there was nothing left to keep track of where the shellcode was, ie a simple CALL reg wasn't possible as by the time i gained control of EIP there was no trace of where i was...so it became a blind guess, and memory gets pretty scattered...never the less, it is exploitable, and i popped up several calc.exe's when testing :)

even if not reliable, i found it an interesting workaround for null-bytes.  carry on if you like, here's the code i was using to test(which is functional, just not reliable):

http://fakehalo.us/xmagiciso_24bit.c