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