Re: re: PaX PoC-exploit.

[Joel Eriksson <je-dailydave () bitnux com>]

On Sun, May 02, 2004 at 02:54:16PM +0200, pageexec () freemail hu wrote:
> [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.

All my Linux boxes use PaX/Grsecurity and when combined with properly
implemented stack smashing protectors, as provided by GCC SSP/ProPolice
for instance, I think it is the single best proactive security measure
against the exploitation of the memory corruption type of bugs.

The problem is that, in my experience, most people see PaX/Grsecurity
as a silver bullet that automagically stops any and all buffer overflows.
Simple stack overflows is still a very common type of vulnerability though,
and PaX alone is not adequate protection against it.

That is not necessarily to be considered a flaw in PaX of course, it is
better to use something like SSP/ProPolice along with PaX. ACLs on top of
that helps a great deal too. Features I would be happy to see in PaX would
be these though:

   Mapping libraries to addresses with NUL-bytes.

   Enforce a minimum delay before a SIGSEGV:ed program can be executed again
   (and before a parent process with a SIGSEGV:ed child can fork() again). 

Btw, in case spender reads this, a feature I would like to see in grsecurity
would be to enforce fd 0, 1 and 2 being open upon execution of SUID/SGID
programs, as with OpenWall that opens /dev/null on those descriptors in case
they are closed. The kind of bugs possible without that feature can be pretty
sneaky.

> what are these conditions?
>
> 1. ability to create an (executable) file
> 2. ability to execute the above created (or arbitrary) executable file

False. Interpreters like Perl, Python or any other of the powerful script
languages could be used to make a similar exploit too (even bash alone
could be used actually).

In case some nitpicker points out that the exploit I made executed another
program prepared by the exploit, it would also have been possible to find
the offset to /bin/sh in libc and execute a shell directly instead.

You also seem to have completely forgotten that this technique can be used
with remote exploits too, in those cases condition one and two obviously
does not apply.

Last but not least, in reality few systems actually enforce strict ACLs
that disallow users from creating and executing files on the system.

Not to mention that some of the systems that disallow execution of
user provided files can be circumvented by executing them indirectly
via the dynamic linker, bugs in "allowed programs", etc or by simply
using an interpreter instead.

> 3. ability to perform linear stack smashing
>
> why are these not true?

"Why may not these be true" or "Why are these not true in all cases"
would have been more appropriate.

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

The PoC does not directly introduce/execute arbitrary code though, it
executes code that already exists in the address space of the process
but in an unintended manner. It simply alters the execution flow.

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

Actually, it's the other way around. My exploit works in the kind of
deployment that is pretty standard and you tell me that the exploit
could have been prevented if properly implemented ACLs were used,
which is of course true. But what if the program that was exploited
should be able to execute /bin/sh under "normal" circumstances (not
that unlikely, since functions like system() and popen() uses it).

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

Of course, SSP prevents this sort of attack, unless there is an information
leakage in the vulnerable program (via a format string bug for instance) or
if one has control over the offset in the buffer to start writing at. Where
did "kernel info leaking" come into the picture..? You mean like listing the
addresses in /proc/<pid>/maps?

> 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).

On this point we can agree too. The PoC did not demonstrate anything that
was not already known. The paper you mentioned used shellcode, so it doesn't
really count, but as far back as in late 2001 Nergal published an excellent
paper on "Advanced return-into-lib(c) exploits" with a case-study on PaX:

   http://www.phrack.org/show.php?p=58&a=4

Relevant excerpt:

  2) One can bruteforce the mmap base. Usually (see the end of 6.1) it                                                  
 
     is enough to guess the libc base. After a few tens of thousands tries, an                                          
      
     attacker has a fair chance of guessing right. Sure, each failed attempt is                                         
      
     logged, but even large amount of logs at 2 am prevent nothing :) Solution:                                         
      
     deploy segvguard [8]. It is a daemon which is notified by the kernel each                                          
      
     time a process crashes with SIGSEGV or similar. Segvguard is able to                                               
      
     temporarily disable execution of programs (which prevents bruteforcing),                                           
      
     and has a few interesting features more. It is worth to use it even without                                        
      
     PaX.                                                                      

The fact that bruteforcing a random value is nothing new is something I
considered too obvious to mention. However, although the technique is
known since ages and obvious for anyone thinking about it I have not yet
seen any exploit take advantage of it, so I think it deserved a PoC.

Actually, many exploit coders that I have shown the exploit for during the
last few months have been rather surprised to see that such an exploit was
still possible with PaX. Since the technique is well known most people seem
to have assumed that PaX had some kind of protection against it by now.

Some people I talked with had assumed more entropy was involved and some
thought libraries were mapped on addresses with NUL-bytes (which is not
a fool-proof protection either of course, but it helps). Some people just
hadn't thought further than "PaX protects against overflows, period".

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

Thanks for the documentation reference. I still don't see why that pseudo
resource cannot be provided without enabling the ACL system.

> > 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).

Ah, so they still don't restrict mprotect()..

-- 
Best Regards,
   Joel Eriksson
-------------------------------------------------
Cellphone: +46-70 228 64 16 Home: +46-26-10 23 37
Security Research & Systems Development at Bitnux
PGP Key Server pgp.mit.edu, PGP Key ID 0x529FDBD1
A615 A1E1 3CA2 D7C2 CFEA 47B4 7EF7 E6B2 529F DBD1
-------------------------------------------------
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
http://www.immunitysec.com/mailman/listinfo/dailydave