PDA

View Full Version : Is this bug exploitable?

LaBBa
September 2nd, 2010, 00:51
Hi
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 ?

Thanks,
LaBBa.
disavowed
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.
LaBBa
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.
Maximus
September 5th, 2010, 04:26
Quote:
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).

Quote:

- DstData is on the stack

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

Quote:

- 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...
disavowed
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?
evaluator
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.
Sab
September 6th, 2010, 13:50
Quote:
[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
evaluator
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?!
evaluator
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.

Code:
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
evaluator
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.