[Bug libc/11892] New: putenv()/setenv() unbounded alloca()

[Bug libc/11892] New: putenv()/setenv() unbounded alloca()

[cdn at chromium dot org]

Setting long environment variables results in errant stack pointer and 
subsequent memory corruption. This is due to an inlined alloca() which can move 
the stack pointer to an arbitrary location in memory.

This can probably be used to gain arbitrary code execution in code which sets 
environment variables where an attacker controls either the name or value 
arbitrarily.

the use of the -fstack-check compile flag probably does not sufficiently 
mitigate these issues.

#include <sys/mman.h>
#include <sys/types.h>

void main(int argc, char **argv) {
  char *name;
  name = mmap(0, atoi(argv[1]), PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
  memset(name, 0x41, atoi(argv[1]));
  name[atoi(argv[1]) - 1] = 0;
  name[atoi(argv[1]) / 2] = '=';
  putenv(name);
  exit(0);
}

within putenv() a sub esp, arbitrary will happen making subsequent writes to the 
stack (in this case in the form of a memcpy() to overwrite arbitrary memory.

-- 
           Summary: putenv()/setenv() unbounded alloca()
           Product: glibc
           Version: 2.11
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: drepper at redhat dot com
        ReportedBy: cdn at chromium dot org
                CC: glibc-bugs at sources dot redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=11892

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/11892] putenv()/setenv() unbounded alloca()

[kees at outflux dot net]

------- Additional Comments From kees at outflux dot net  2010-09-12 15:34 -------
In /proc/$pid/maps:

fffdd000-ffffe000 rw-p 00000000 00:00 0                                  [stack]

And from the registers after a crash running this as "./env 100000000":

esp            0xfd04e510	0xfd04e510

This appears to "just" be a case of running out of stack memory. Doing
breakpoints before/after the putenv, it looks like stack memory is being
accounted for correctly, so I'm not clear how this could cause corruption:

(gdb) run 10000
Breakpoint 1, main (argc=2, argv=0xffffd6b4) at env.c:13
13	  putenv(name);
(gdb) info reg
...
esp            0xffffd5d0	0xffffd5d0
(gdb) cont
Continuing.

Breakpoint 2, main (argc=2, argv=0xffffd6b4) at env.c:14
14	  return 0;
(gdb) info reg
...
esp            0xffffd5d0	0xffffd5d0


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING


http://sourceware.org/bugzilla/show_bug.cgi?id=11892

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/11892] putenv()/setenv() unbounded alloca()

[kees at outflux dot net]

------- Additional Comments From kees at outflux dot net  2010-09-12 15:40 -------
Ah, as pointed out by the reporter in separate email, this could be a serious
problem for threaded applications.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW


http://sourceware.org/bugzilla/show_bug.cgi?id=11892

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/11892] putenv()/setenv() unbounded alloca()

[kees at outflux dot net]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kees at outflux dot net


http://sourceware.org/bugzilla/show_bug.cgi?id=11892

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.