On Tue, Oct 11, 2005 at 04:20:26PM +0000, bannedit@xxxxxxxxxxxxxxx wrote:
> Very nice Steve it appears you've made a lot of improvements to the
> older version.
Yeah I've been getting annoyed by how sloppy the code is.
To be honest I think it's almost worth combining the two programs
env-overflow + cmd-overflow into one binary. That way the could share
argument processing, and a shellcode library.
I've not really been too motivated for that though just yet, although
after importing the code into CVS I make a couple of quick cleanups.
As things stand they both mostly work most of the time - and writing
exploits tends to get dull pretty fast. Once you can do one class of
holes you can do almost all instances of that class..
> The method I use on local exploits is to setup an
> environment variable containing the shellcode. So in the case of a env
> variable being the cause of the overflow the last env variable is
> pushed on the stack first (LIFO) so we can calculate the exact return
> address by using the start of the stack as a reference.
I see. Neat :)
> 0xc0000000 - strlen(progname) - strlen(shellcode) - 0x02
>
> will give an exact return address to the start of the shellcode without
> the use of any nop padding.
Yes.
> This paper describes the method in detail:
> http://packetstormsecurity.org/groups/netric/envpaper.pdf
Cheers for the link.
Steve
--
|
