|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
Subject: Re: Future of buffer overflows ?
From: tseeker
PROBEMAIL.COMDate: Thu Nov 02 2000 - 04:13:53 CST
- Next message: Gerald Carter: "Re: Samba 2.0.7 SWAT vulnerabilities"
- Previous message: PaX: "some PaX Q&A"
- Maybe reply: tseeker
PROBEMAIL.COM: "Re: Future of buffer overflows ?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> Feed a return address and arguments so the RET "calls" memcpy >(),
> and use this memcpy() to move the buffer to some place in
> memory where
> you can jump latter. Then tell memcpy() to return to this new > place,clarifying:
memcpy needs an argument specifying the amount of bytes to
copy. It will contain 0, so you will have problems with putting
it on the stack. strcpy() is a better choice. This technique
was first described (some years ago) in "Defeating Solar
Designer non-executable stack patch" by Nergal
http://www.securityfocus.com/archive/1/8470
check it out, the second method can be used to bypass Pax
protection as well. It additionally deals with the case when
libc is mapped into a region with address which begins with NULL.
> The second option... let's call it "pop&ret"
That is pretty cool.
The Seeker
ProbeMail / http://www.probemail.com
- Next message: Gerald Carter: "Re: Samba 2.0.7 SWAT vulnerabilities"
- Previous message: PaX: "some PaX Q&A"
- Maybe reply: tseeker
PROBEMAIL.COM: "Re: Future of buffer overflows ?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]