re: PaX PoC-exploit.

[pageexec () freemail hu]

[please CC on responses]

> Unless combined with something like SegvGuard, that stops programs
> that segfaults to be executed again for a certain period of time, it
> seems like Grsecurity/PaX does not do much good for protecting against
> simple stack overflows.

this 'proof of concept' exploit code relies on a few conditions
that are not present in a properly deployed grsec/PaX/etc system
(think Adamantix or Hardened Gentoo) therefore i'd like to put
Joel's conclusion that "Grsecurity/PaX does not do much good for
protecting against simple stack overflows" into perspective.

what are these conditions?

1. ability to create an (executable) file
2. ability to execute the above created (or arbitrary) executable file
3. ability to perform linear stack smashing

why are these not true?

1. read-only chroot or similar ACLs for the target.

   note that for a remote exploit it's often the exploit that would
   have to create the to-be-executed file, this PoC does not show
   that at all - it's less trivial than this local exploit because
   you would have to chain multiple library calls (and that means
   knowing more offsets and at least on Gentoo that won't be easy).

   and even if a given target is allowed to create/write to files,
   there's the next step:

2. TPE or ACLs prevent execution of arbitrary files (at the mmap()
   level, so we're not only talking of execl() and family). note
   i'm talking of what the attacked program can execute, not the
   attacker himself (i.e., the fact that local users can create
   and run their own exploits is irrelevant ;-). of course if you
   have a kernel bug that circumvents these, then all bets are off,
   but it's not specific to PaX/grsec then.

   when i stated in the PaX docs that PaX can be used to prevent the
   introduction/execution of arbitrary code (which is that this PoC
   relies on), it wasn't a figure of speech, it's reality and Joel's
   PoC doesn't prove it wrong either.

   of course it's perfectly fine to exploit a weakened deployment but
   then please say so, otherwise the casual reader will misunderstand
   your conclusions.

3. ssp prevents this (in a probabilistic sense, that's 32 bits of
   entropy to get right), at least as long as you don't have some
   nice kernel info leaking ;-). obviously assuming different or more
   complex bugs can/will circumvent ssp, but then again, Joel was
   talking of 'simple stack overflows' himself. oh, and before someone
   wants to point out char buf[4], ssp's had -fstack-protector-all for
   a while now.

my conclusion about this PoC is that it didn't demonstrate anything
that wasn't already known, and in fact it's not even the first one
of this kind: http://www.but.pl/~xfer/papers/mmap_bf.txt (this one
also uses a weakened attack model to get around stack randomization
and execute injected shellcode, the latter is of course not possible
when using proper non-exec pages).

> Surprisingly, when examining the grsecurity-code a while ago I noticed
> that there is actually code there that enforces a minimum delay before a
> segfaulted program can be executed again, but that it is only enabled if
> the ACL-system is used.

grsecurity's RES_CRASH is a pseudo resource, details are in the manual:
http://www.grsecurity.net./gracldoc.htm#Resource_Restrictions .

> I wonder how W^X deals with these kind of attacks.

in OpenBSD you have random library bases/ordering, so you have to brute
force that. then you can return to mprotect/etc and increase the executable
range limit (that is, force the kernel to switch to the normal user code
segment) and then execute the injected payload directly, no need to mock
with file creation. or you can do the same by returning into a 'retf' with
a properly prepared stack. oh, and you have ssp of course but with kernel
info leaking bugs it's possible to get around it (at least in local attacks).

_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://www.immunitysec.com/mailman/listinfo/dailydave