[SECURITY] glibc contains paths to useful binaries

[John Moser]

glibc contains a number of useful stings, visible by (strings /lib/libc.so.6 |grep '^/' | less). A more interesting grep shows the following:

 strings /lib/libc.so.6 |grep '^/' | grep 'bin'

/bin/sh
/bin:/usr/bin
/bin/csh
/etc/bindresvport.blacklist

This grep covers any absolute path including 'bin', such as /bin, /sbin, /usr/bin, /usr/local/sbin, or the like. Notice the '/bin/sh' and '/bin/csh' paths.

The strings '/bin/sh' and '/bin/csh' being in glibc allows attackers to ignore stack base randomization (19 bits on x86, can be attacked to decrease to maybe 6 bits?) and concentrate on library randomization during a ret2libc attack. The ret2libc attack must focus on guessing the base of glibc, and calculating the address of system() from this base; in such a successful attack, the injected stack frame pointer can point directly to a string indicating such a useful program in glibc, similarly calculated from the now known (during a successful attack) base address of glibc.

Ideally, the attacker would have to guesses two independent random values. First, the attacker would have to guess the mmap() base, affected by 16 bits of entropy, to calculate the base address of glibc, to in turn calculate the address of system() (or any other function). Then, the attacker would have to guess the stack base, affected by 19 bits of entropy. Total, the attacker has to break 35 bits of entropy; 64-bit systems such as x86-64 can allow 28 or 32 bits for each of these, so the entropy becomes 56-64 bits.

In reality, the attacker can, in the specific case of trying to get a command shell, simply break mmap() base randomization. Further, the attacker may in some cases have the opportunity to inject data into a known location in the heap, in which case correcting this bug does not afford the improved protection of additional entropy; see bug #139436 for a solution to that.

Please remove these from glibc. Perhaps replacement with '/bin' and a separate 'sh' or 'csh' string (which gets a null between these at the very least) would work; or, perhaps glibc does not need these strings and can remove them entirely.

Some other strings in glibc may also cause trouble. More research will handle this; try the command (strings /usr/lib/libc.so.6 | egrep -w '(bin|lib)').

[Kees Cook (kees)]

Hopefully the future "pointer encryption" routines in libc will help head this off as well. Patches are welcome, though I suspect, as you say, there are many more things beyond just "/bin/sh" in the libc code, including possible register build-up chaining[1], which would be nearly impossible to stop without lots of work.

[1] http://www.suse.de/~krahmer/no-nx.pdf