Re: Sabotaged PaXtest (was: Re: Patch 4/6 randomize the stack pointer)

[Julien TINNES]

> 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

It depends on what you call 'code injection'.

- If code injection is the introduction of a new piece of directly 
executable-by-processor opcodes (I exclude interpreted code here) into a 
running process:

	1. If you trust the Linux kernel, your processor, etc..
	2. If you have a non executable pages semantics implementation
	3. If you have a restriction preventing PROT_EXEC|PROT_WRITE mappings 
from existing and any new PROT_EXEC mapping (meaning giving an existing 
mapping PROT_EXEC or creating a new PROT_EXEC mapping) from being created.

then the answer is yes.

PaX does 2 fully, and 3 partially:
 - It does'nt prevent executable file mapping (access control system must)
 - .text relocations are detected and permited if the option is enabled 
(necessary if you don't have PIC code)
 - there is an option that can be enable to emulate trampolines

But if you consider code injection as in your previous post:

>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?

then the answer to your question is no because a stack overflow usually 
allows two things: injection of new code, and execution flow redirection.
While the former is prevented, the later is not and the attacker could 
use chaining techniques as in [1] to execute "arbitrary code" (but not 
directly as an arbitrary, newly injected sequence of opcodes).
Address space obfuscation (address space layout randomization is one 
way) is making it harder (but not impossible, esp. if you don't have 
anything preventing the attacker from bruteforcing...) to use existing code.

[1]: Nergal, Advanced return into-lib(c) 
http://www.phrack.org/show.php?p=58&a=4


--
Julien TINNES - & france telecom - R&D Division/MAPS/NSS
Research Engineer - Internet/Intranet Security
GPG: C050 EF1A 2919 FD87 57C4 DEDD E778 A9F0 14B9 C7D6
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/