View Full Version : Is this bug exploitable?

September 2nd, 2010, 00:51
i have found a bug during my reversing and i'm not sure it is exploitable i converted the ASM to C code so it would be easier to understand:

memcpy(*DstData, Msg->data, Msg->dataLength);

Msg->data acctual size is only 4 bytes
DstData is maximum size of 256 bytes

what i can control is the Msg->dataLength
i can set a larger value the the Msg->data size.

the exception i get is : "..access to invalid memory.."

is this bug can be somehow exploited via maybe Heap ?


September 2nd, 2010, 16:33
By "exploitable", I assume you mean code execution.

Depends on whether or not you can control what's after the 4 bytes of Msg->data. Reliability also may depend on whether DstData is on the stack or heap, and if GS, NX, and ASLR are used.

Feel free to msg me with details of the target if you'd like some help.

September 5th, 2010, 02:43
- 4 bytes of Msg->data can be controled.
- DstData is on the stack
- GS is in use
- ASLR not in use.

September 5th, 2010, 04:26
4 bytes of Msg->data can be controled.

well, you can exploit with even 1 byte, as long as you can overwrite the EBP pushed initially by a call with stack frame (not trivial, but possible).


- DstData is on the stack

see http://en.wikipedia.org/wiki/Buffer_overflow#Heap-based_exploitation


- ASLR not in use.

ASLR is only useful when your exploits hardcode directly DLL functions addresses!!!
this technique is just a quick&dirty solution, and aslr only targets it.
Way better: you can access always valid, IAT pointers in the main executable. ASLR never touch the main exe because 98% of exe files are with relocation symbols stripped... Also, say you exploited a system DLL: what prevents you to |&64k, MZ found? -$1000 and loop| and then just moving to interesting IAT/EAT? Well, surerly it requires a little more space, but not all that much to good assembler coders. So, a bit more asm effort to get an always reliable access to API...

September 6th, 2010, 04:36
If you have absolutely no control over the data in memory more than 4 bytes after the beginning of Msg->data then it'll be hard to do any kind of reliable code execution and you likely will just have a DoS. Is Msg->data a global buffer or is it on the heap? If the former, do you control anything in global memory after that buffer?

September 6th, 2010, 06:55
cmon, IMHO these forums are not for exploit-builders help..
why should we do such things anyway?
if you are concerned about software's quality, then notify authors about bug.

September 6th, 2010, 13:50
[Originally Posted by evaluator;87687]cmon, IMHO these forums are not for exploit-builders help..
why should we do such things anyway?
if you are concerned about software's quality, then notify authors about bug.

I would argue to help, not if you are strictly thinking exploit writing. But exploits and reverse engineering are extremely tied together. Most notably the latest ps3 jailbreak. I also had to code an unusual exploit to read out memory from a hw device for dumping its internal keys/memo contents. DONGS

September 10th, 2010, 11:37
BTW, i enabled full-DEP & discovered quite programs, which are jumping to non-exec memory & that jumps looks simply errors (without DEP they are handled by SEH).
so DEP gives yet another filter for unwanted exceptions

for example GoogleTalk. should we research?!

September 11th, 2010, 13:44
here i get problem. progy builds some kind of patch-redirector for WndProc.
i think, best way for correction is to create VAlloc patch.

CPU Disasm
Address Hex dump Command Comments
004013F3 /$ 8B4424 08 MOV EAX,DWORD PTR SS:[ARG.2] ; googletalk.004013F3(guessed Arg1,Arg2)
004013F7 |. 8941 04 MOV DWORD PTR DS:[ECX+4],EAX
004013FA |. 8B4424 04 MOV EAX,DWORD PTR SS:[ARG.1]
004013FE |. 2BC1 SUB EAX,ECX
00401400 |. 6A 0D PUSH 0D ; /Size = 13.
00401402 |. 83E8 0D SUB EAX,0D ; |
00401405 |. 51 PUSH ECX ; |Base => ARG.ECX
00401406 |. C701 C7442404 MOV DWORD PTR DS:[ECX],42444C7 ; |
0040140C |. C641 08 E9 MOV BYTE PTR DS:[ECX+8],0E9 ; |
00401410 |. 8941 09 MOV DWORD PTR DS:[ECX+9],EAX ; |
00401413 |. FF15 F0725800 CALL DWORD PTR DS:[<&KERNEL32.GetCurrentProcess ; |[KERNEL32.GetCurrentProcess
00401419 |. 50 PUSH EAX ; |hProcess
0040141A |. FF15 F4725800 CALL DWORD PTR DS:[<&KERNEL32.FlushInstructionC ; \KERNEL32.FlushInstructionCache
00401420 \. C2 0800 RETN 8

00401423 /$ 56 PUSH ESI ; googletalk.00401423(guessed Arg1,Arg2)
00401424 |. 8BF1 MOV ESI,ECX
00401426 |. 833E 00 CMP DWORD PTR DS:[ESI],0
00401429 |. 75 13 JNE SHORT 0040143E
0040142B |. 6A 0D PUSH 0D ; /Size = 13.
0040142D |. 6A 04 PUSH 4 ; |Flags = HEAP_GENERATE_EXCEPTIONS
0040142F |. FF15 E8725800 CALL DWORD PTR DS:[<&KERNEL32.GetProcessHeap>] ; |[KERNEL32.GetProcessHeap
00401435 |. 50 PUSH EAX ; |Heap
00401436 |. FF15 EC725800 CALL DWORD PTR DS:[<&KERNEL32.HeapAlloc>] ; \NTDLL.RtlAllocateHeap
0040143C |. 8906 MOV DWORD PTR DS:[ESI],EAX
0040143E |> FF7424 0C PUSH DWORD PTR SS:[ARG.3] ; /Arg2
00401442 |. 8B0E MOV ECX,DWORD PTR DS:[ESI] ; |
00401444 |. FF7424 0C PUSH DWORD PTR SS:[ARG.3] ; |Arg1
00401448 |. E8 A6FFFFFF CALL 004013F3 ; \googletalk.004013F3
0040144D |. 5E POP ESI
0040144E \. C2 0800 RETN 8

September 11th, 2010, 14:49
damnIt, now i'm curious, why same DEP-exception not happens under "OptOut" mode?!!
(only happens under "AlwaysOn"
and why for some kind of programs this "OptOut" mode is automatically disabled without user's notification??

EDIT: exception under "OptOut" IS triggered but then system overrides it.