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
_______________________________________________
kernel mailing list
kernel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/kernel
