| 1 |
On Sunday, January 28, 2007 01:54, pageexec@××××××××.hu wrote: |
| 2 |
> On 28 Jan 2007 at 0:06, gentoo-hardened-ml-01@××××××.org wrote: |
| 3 |
> > My question is, if you have a program that breaks with PaX's |
| 4 |
> > SEGMEXEC/PAGEEXEC, then it should break, too, under SSP/ProPolice, |
| 5 |
> > correct? |
| 6 |
> |
| 7 |
> no, these mechanisms catch bugs/exploits at different stages. |
| 8 |
> e.g., ssp would detect a simple stack buffer overflow at the |
| 9 |
> time the attacked function returned to its caller, PaX would |
| 10 |
> detect it if the attacker supplied return address pointed to |
| 11 |
> non-executable memory. |
| 12 |
> |
| 13 |
> > So if I have a program that breaks with SEGMEXEC/PAGEEXEC and I'm |
| 14 |
> > using a full-on hardened setup with SSP/ProPolice, I could disable |
| 15 |
> > PaX's SEGMEXEC/PAGEEXEC for that program, but it would still break |
| 16 |
> > because then SSP/ProPolice would catch and kill it, correct? |
| 17 |
> |
| 18 |
> also no. in general, PaX catches runtime code generation and |
| 19 |
> execution attempts, ssp catches simple stack buffer overflows. |
| 20 |
> as i explained in the previous mail, quake3 does the former, |
| 21 |
> but (hopefully) not the latter so i think you'll be fine with |
| 22 |
> ssp. take note of http://bugs.gentoo.org/show_bug.cgi?id=135265 |
| 23 |
> however, ssp has code generation bugs with no fixes in sight, |
| 24 |
> although so far we haven't seen them in C code i think. |
| 25 |
|
| 26 |
Ok, I think I have it. PaX detects and intercepts attempts to execute code on |
| 27 |
a non-executable stack. SSP/ProPolice detects actual overflows upon return |
| 28 |
to the caller, but will not necessarily stop a program from "legitimately" |
| 29 |
executing a non-executable stack if that execution would not result in a |
| 30 |
stack overflow. Is this correct? |
| 31 |
|
| 32 |
Thanks for the bug link too, very good to know. |
| 33 |
-- |
| 34 |
gentoo-hardened@g.o mailing list |
Archives