Re: 3COM TFTPD Overflow: SEH Overwrite

[lists-76]

What vulnerability are you trying to exploit? This one?

http://www.securityfocus.com/bid/21322


In your document, you say

"I look for POP/POP/RET ws2_32.dll (to avoid SafeSEH restrictions?)"

are you telling or asking? Can you please provide a little more info.
Otherwise it is hard to help here. If you try to exploit the
vulnerability mentioned above, send the following request (perl style):

$buffer="\x00\x01";
$buffer .=("\x41\x00");
$buffer .=("A"x480);

That should give you control over eip. By selecting the right return
address, you end up in a reliable exploit.





Quoting jeremy.junginger@...:

> I'm attempting to exploit an already known bug in 3COM TFTPD server,  
>    and execute "calc.exe" with my shellcode.  I have control of    
> ECX/EIP, and can overwrite both SEH and pointer to next SEH    
> successfully, and have used:
>
> Pointer to next SEH: \xeb\x10\x90\x90
> SEH: \x69\x12\xab\x71 (POP/POP/RET in  ws2_32.dll)
>
> A full writeup with screenshots is available at:
> http://filebin.ca/pmuwqm/SEHOverwrite.rtf
>
> I'm getting "Debugged program was unable to process exception", so I  
>    hit shift+f9 (in olly) and it terminates with some strange exit    
>  code.  Could you take a peek and see what I'm missing here?
>
> Thanks guys!
>
> -jj
>

[jeremy.junginger]

I was asking if ws2_32.dll was compiled with SafeSEH (didn't know about the Olly plugin).  Regarding the return address...I already have control of EIP, but can't point it directly to the stack, so I'm searching for a module with a suitable return address (with pop/pop/ret) to help me get back to that buffer.  The issue was with the return address I was pointing to, and the fact that it the module was compiled with SafeSEH.  Is that enough detail?  

[lists-76]

Quoting jeremy.junginger@...:

> I was asking if ws2_32.dll was compiled with SafeSEH (didn't know    
> about the Olly plugin).  Regarding the return address...I already    
> have control of EIP, but can't point it directly to the stack, so    
> I'm searching for a module with a suitable return address (with    
> pop/pop/ret) to help me get back to that buffer.  The issue was with  
>   the return address I was pointing to, and the fact that it the    
> module was compiled with SafeSEH.  Is that enough detail?
>


Nope, you didn't answer my question regarding the vulnerability you
are trying to exploit. If it turns out to be the transporting mode
issue, than the best place to look for a working return address is the
binary itself. Very reliable and still enough space for the shellcode.

regards
-S

----------------------------------
SkillTube.com