On Sunday, January 28, 2007 01:54, [EMAIL PROTECTED] wrote: > On 28 Jan 2007 at 0:06, [EMAIL PROTECTED] wrote: > > My question is, if you have a program that breaks with PaX's > > SEGMEXEC/PAGEEXEC, then it should break, too, under SSP/ProPolice, > > correct? > > no, these mechanisms catch bugs/exploits at different stages. > e.g., ssp would detect a simple stack buffer overflow at the > time the attacked function returned to its caller, PaX would > detect it if the attacker supplied return address pointed to > non-executable memory. > > > So if I have a program that breaks with SEGMEXEC/PAGEEXEC and I'm > > using a full-on hardened setup with SSP/ProPolice, I could disable > > PaX's SEGMEXEC/PAGEEXEC for that program, but it would still break > > because then SSP/ProPolice would catch and kill it, correct? > > also no. in general, PaX catches runtime code generation and > execution attempts, ssp catches simple stack buffer overflows. > as i explained in the previous mail, quake3 does the former, > but (hopefully) not the latter so i think you'll be fine with > ssp. take note of http://bugs.gentoo.org/show_bug.cgi?id=135265 > however, ssp has code generation bugs with no fixes in sight, > although so far we haven't seen them in C code i think.
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? Thanks for the bug link too, very good to know. -- [email protected] mailing list
