Re: Unexecutable Stack / Buffer Overflow Exploits...

[Anton Ivanov]

-----BEGIN PGP SIGNED MESSAGE-----

On 03-Jan-2000 Theodore Y. Ts'o wrote:
>    Date:   Mon, 3 Jan 2000 11:42:34 -0500 (EST)
>    From: Gregory Maxwell <[e-mail]>
> 
>    I have a statement which I like you to affirm or deny. It will clear up a
>    lot of things I think.
> 
>    "If there is a remotely exploitable stack-smash attack for *ANY*
>    userspace application or daemon (i.e. Netscape or Sendmail) running
>    on ia32 Linux without the Solar Designer No-exec-patch, then there
>    *must* exists an exploit for that application on ia32 Linux *WITH*
>    that patch applied."
> 
> Let me modify that statement a little bit, just to make things more
> concrete.    IF the following conditions applies:
> 
>       * There is an application which has has an exploitable
>               stack-smash attack on an IA32 Linux system, AND
>       * The attacker has access (or can recreate) to the binary
>               (otherwise you're depending on security through
>               obscurity), AND
>       * The the program is using any one of a number of simple, basic
>               libc functions (this rules out trivial, non-real-world
>               applications):
>                       open, unlink, exec, rename, chmod, chown
>                       (and in most cases(!): memcpy and strcpy)
> 
> THEN a knowledgeable attacker will be able to construct an attack which
> will cause harm to that system even with the Solar Designer
> no-exec-patch enabled.
> 
> Why do I say that?  Because what you can do is overwrite the stack in a
> carefully designed way to transfer control to that function, which can
> then do damage.  For example supose your real-life application has a
> single call to strcpy() anywhere in the text segement.  Then all you
> have to do is to overrun the stack in the following way:
> 
> B--->         ptr to static buffer in data segment
>               padding (to cover local variables)
>               ptr to static buffer in data segment
>               ptr to attack code (see below)
> A--->         ptr to "call strcpy" instruction in text segment
>               padding (to cover local variables)
>               copy of attack code
> 
> 
> After the stack is overrun, the last thing the function does is adjust
> the stack pointer to the end of its stack frame "A" and then it
> returns.  However, the stack at "A" contains not a pointer into
> executable code on the stack (since we're assuming the stack might be
> non-executable) but rather, to a "call strcpy" instruction in the text
> segment.  This causing a call to the libc function, which will then copy
> the attack code into the data buffer, and then return to the middle of
> whatever function the strcpy() call was contained in.  When that
> function returns (you ideally pick a function where the call to strcpy
> is one of the last things that function does), that stack frame gets
> destroyed, and now the return address at statck stack location "B"
> transfers control to the data segment where the attack code has been
> copied, and viola!  It's off to the races.
> 
> (I just recently came up with the generalized memcpy/strcpy exploit, and
> I'm pretty proud of it.  It should work on most real-world binaries with
> a stack-smashing vulnerability, even on a machine with the non-exec
> stack hack patch installed.)

In order to get something usefull done you will have to repeat the exploit
sequence several times (setting up args and calling different functions).

This is fine with daemons that fork for every connection so you start with a
clean state every time. This is also good for local exploits.

At the same time, this is likely to sooner or later crash a vulnerable daemon
that does not fork for serving new connections (especially a stateful daemon
that keeps some state info on connections). The reason being that a daemon with
an exploitable bug it is not likely to survive being passed bogus arguments time
after time (example - named). In other words - the technique you describe has a
wide application but not as wide as a simple stack smash on an exec stack
system. So having the stack non-exec and libs mapped to an address containing
0x00:
1. Raises the bar quite a bit (though not as high as exepected). 
2. Makes the exploits for Linux and for stack-exec systems like Solaris, etc
quite different which gives everyone some additional space to maneuvre.

> 
[snip]

- ----------------------------------
Anton R. Ivanov
IP Engineer Level3 Communications
RIPE: ARI2-RIPE      E-Mail: Anton Ivanov <[e-mail]>
@*** Drucker's Dicta:  (No 11 of 15) ***
      Medicare and Medicaid are the greatest measures yet devised to make
      the world safe for clerks.

- ----------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iQEVAwUBOHIWZilWAw/bM84zAQGinAf9GXhsIqmqnsrUjPlYbhwbQU3C+KLJHOH7
4HnA57pZqd6stuzDgD+puhP488N3excf2WzVc7OKp6ewGGnpPm9Vg4rAbveLIZQI
k+ldAnDLTSw/CRIFjkKyLc5fIOZnwPaVprnn0LrKL8XAYOdAKyy0hyBM1JlBHPjw
8codOFJ/aGfjZozA4tkW6TnIMMjV2C6PdvqjE/qQTT0rVMGXlVFP6Tc5Aw36gnD/
YgrIu1p3boHnov/6WGAMncShkDH4LqGCLfc9qnH0LgSHkesBHIOFfWIqcBhKTSqm
koZkj46d16oCYMl7sKCh6Ib0lIa5iETFWhrR+59wScZH4uD9t7yrgg==
=GwaS
-----END PGP SIGNATURE-----