> I'm no security expert, so bear with me here; I just kind of tripped
> over something interesting that I'd like to ask about.
>
> I was blogging about DEP based on MS' technical documentation and came
> up with a quick and dirty way to use a buffer overflow (we'll assume no
> stackguarding, or that you found a way around it i.e. using a format
> string bug) to kick DEP out of the way. This is pretty much based on
> the PaX documentation and justification for mprotect() restrictions.
Look for return-into-libc exploits. There are quite a few.
Even with non-executable stack and heap, no one guarantees that buffer
overflows aren't exploitable. Randomization of load addresses is
intended to provide additional protection, but the number of available
bits is fairly low on 32 bit machines (problably less than 16). I
don't know if Windows is doing it.
> I'm no security expert, so bear with me here; I just kind of tripped
> over something interesting that I'd like to ask about.
>
> I was blogging about DEP based on MS' technical documentation and came
> up with a quick and dirty way to use a buffer overflow (we'll assume no
> stackguarding, or that you found a way around it i.e. using a format
> string bug) to kick DEP out of the way. This is pretty much based on
> the PaX documentation and justification for mprotect() restrictions.
Look for return-into-libc exploits. There are quite a few.
Even with non-executable stack and heap, no one guarantees that buffer
overflows aren't exploitable. Randomization of load addresses is
intended to provide additional protection, but the number of available
bits is fairly low on 32 bit machines (problably less than 16). I
don't know if Windows is doing it.
[ reply ]