upstream exec-shield git tree

[Dave Jones]

On Tue, Nov 09, 2010 at 11:32:25AM -0800, Kees Cook wrote:
 > On Tue, Nov 09, 2010 at 10:54:51AM -0800, Kees Cook wrote:
 > > I suspect another factor may be that paxtest can give inconsistent output
 > > when doing the ASLR test.
 > 
 > Actually, in looking at paxtest, it's reporting correctly. I'm not sure
 > what other patches are in the Fedora kernel, but it seems like while
 > Ubuntu's entropy with ascii-armor aslr is bad, Fedora's is even worse.
 > 
 > Fedora 13:
 > 
 > $ for i in $(seq 1 1000); do cat /proc/self/maps | grep 'x.*/lib/.*libc'; done | sort | uniq -c | sort -n
 >     110 00110000-00296000 r-xp 00000000 fd:00 97601      /lib/libc-2.12.so
 >     890 00904000-00a8a000 r-xp 00000000 fd:00 97601      /lib/libc-2.12.so
 > 
 > Ubuntu 10.04:
 > 
 > $ for i in $(seq 1 1000); do cat /proc/self/maps | grep 'x.*/lib/.*libc'; done | sort | uniq -c | sort -n
 > ...[768 lines of differing addresses]...
 >       3 00de3000-00f36000 r-xp 00000000 fb:01 130850 /lib/tls/i686/cmov/libc-2.11.1.so
 >     174 00110000-00263000 r-xp 00000000 fb:01 130850 /lib/tls/i686/cmov/libc-2.11.1.so

That's.. odd.  When I run this on a 32bit (f14) host, I see 764 different addresses, culminating in..
      3 00810000-0099d000 r-xp 00000000 08:01 216978     /lib/libc-2.12.90.so
    162 00110000-0029d000 r-xp 00000000 08:01 216978     /lib/libc-2.12.90.so

I'm curious why it favors SHLIB_BASE so often with no offset.

But for 64-bit it's even worse. I don't see any randomisation at all here.
Something is seriously broken.

	Dave