On 28 Jan 2007 at 3:22, [EMAIL PROTECTED] wrote: > Ok, I think I have it. PaX detects and intercepts attempts to execute code > on > a non-executable stack. SSP/ProPolice detects actual overflows upon return > to the caller, but will not necessarily stop a program from "legitimately" > executing a non-executable stack if that execution would not result in a > stack overflow. Is this correct?
almost ;-). PaX catches execution attempts in any kind of non-exec memory, be that the stack or heap or something else. second, ssp does not concern itself with code execution on the stack per se, rather, it wants to ensure that the saved return address on the stack isn't modified by a buffer overflow (these two things are orthogonal, you can execute code on the stack without overflowing any buffer, and you can overflow a buffer without triggering code execution on the stack). on a non-executable stack (e.g., that PaX creates) nothing can be executed, regardless of ssp (that's why it's called non-executable). ssp also doesn't prevent legitimate stack execution attempts (e.g., nested function trampolines) because they're not triggered by stack overflows. lastly, i think you meant "would not be the result of" instead of "would not result in" (in an attack, shellcode execution follows the overflow, not the other way around), and yes, ssp isn't triggered as long as its canary is left intact. -- [email protected] mailing list
