Messages in this thread | | | Date | Tue, 8 Feb 2005 14:41:56 +0100 | From | Ingo Molnar <> | Subject | Re: Sabotaged PaXtest (was: Re: Patch 4/6 randomize the stack pointer) |
| |
* pageexec@freemail.hu <pageexec@freemail.hu> wrote:
> > btw., do you consider PaX as a 100% sure solution against 'code > > injection' attacks (meaning that the attacker wants to execute an > > arbitrary piece of code, and assuming the attacked application has a > > stack overflow)? I.e. does PaX avoid all such attacks in a guaranteed > > way? > > your question is answered in http://pax.grsecurity.net/docs/pax.txt > that i suggested you to read over a year ago. the short answer is that > it's not only about stack overflows but any kind of memory corruption > bugs, and you need both a properly configured kernel (for PaX/i386 > that would be SEGMEXEC/MPROTECT/NOELFRELOCS) and an access control > system (to take care of the file system and file mappings) and a > properly prepared userland (e.g., no text relocations in ELF > executables/libs, which is a good thing anyway).
i'm just curious, assuming that all those conditions are true, do you consider PaX a 100% sure solution against 'code injection' attacks? (assuming that the above PaX and access-control feature implementations are correct.) Do you think the upstream kernel could/should integrate it as a solution against code injection attacks?
Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |