1 |
On 28 Jan 2007 at 3:22, gentoo-hardened-ml-01@××××××.org wrote: |
2 |
|
3 |
> Ok, I think I have it. PaX detects and intercepts attempts to execute code on |
4 |
> a non-executable stack. SSP/ProPolice detects actual overflows upon return |
5 |
> to the caller, but will not necessarily stop a program from "legitimately" |
6 |
> executing a non-executable stack if that execution would not result in a |
7 |
> stack overflow. Is this correct? |
8 |
|
9 |
almost ;-). PaX catches execution attempts in any kind of non-exec |
10 |
memory, be that the stack or heap or something else. |
11 |
|
12 |
second, ssp does not concern itself with code execution on the stack |
13 |
per se, rather, it wants to ensure that the saved return address on |
14 |
the stack isn't modified by a buffer overflow (these two things are |
15 |
orthogonal, you can execute code on the stack without overflowing any |
16 |
buffer, and you can overflow a buffer without triggering code execution |
17 |
on the stack). |
18 |
|
19 |
on a non-executable stack (e.g., that PaX creates) nothing can be |
20 |
executed, regardless of ssp (that's why it's called non-executable). |
21 |
ssp also doesn't prevent legitimate stack execution attempts (e.g., |
22 |
nested function trampolines) because they're not triggered by stack |
23 |
overflows. |
24 |
|
25 |
lastly, i think you meant "would not be the result of" instead of |
26 |
"would not result in" (in an attack, shellcode execution follows the |
27 |
overflow, not the other way around), and yes, ssp isn't triggered |
28 |
as long as its canary is left intact. |
29 |
|
30 |
-- |
31 |
gentoo-hardened@g.o mailing list |