[17454] in bugtraq
Re: Future of buffer overflows ?
daemon@ATHENA.MIT.EDU (Gerardo Richarte)
Wed Nov 1 22:38:48 2000
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <39FE1E1D.CAAD4928@core-sdi.com>
Date: Mon, 30 Oct 2000 22:16:15 -0300
Reply-To: Gerardo Richarte <core.lists.bugtraq@CORE-SDI.COM>
From: Gerardo Richarte <core.lists.bugtraq@CORE-SDI.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
too many typos... too many errors, too bad english...
Gerardo Richarte wrote:
>
> [buffer] &caller ; before overflow
>
> [buffer] &buffer ; returning to buffer
>
> [/bin/sh] &system xxxx &buffer ; calling system("/bin/sh")
this are stacks... [top ---> bottom]
[buffer] is the overflown buffer,
what follows is the place for the return address,
&caller is the orignal caller, nothing has been changed.
we write &buffer so RET jumps to our code... etc.
> Here I present a way to code any program, or almost any program,
> in a way such that it can be fetched into a buffer overflow in a
> platform where the stack (and any other place in memory, but libc)
> is executable:
^^^^^^^^^^^^^^ is not executable, of course
> pop something
> pop something ; some pops into regs
> pop something
> popbp:
> mov esp,ebp
> pop ebp
> ret
this should have been:
pop something
pop something ; some pops into regs
pop something
movesp:
mov esp,ebp
popbp:
pop ebp
ret
and for changing the stack pointer, we need something a little
more complicated than:
> [buffer] ... &popbp buffer+BUF_SIZE
something like:
[buffer] ... &popbp buffer+BUF_SIZE &movesp
I think this will make it.
Well, now it's a little better... sorry for the confusion.
again, richie
--
A390 1BBA 2C58 D679 5A71 - 86F9 404F 4B53 3944 C2D0
Investigacion y Desarrollo - CoreLabs - Core SDI
http://www.core-sdi.com
--- For a personal reply use gera@core-sdi.com
