[Security] Heap and PIE randomization

[John Moser]

Binary package hint: linux-image-generic

Currently the kernel randomizes the stack base and mmap() base. The mmap() base covers libraries, file-backed mmap() segments (i.e. libraries), and anonymous data segments (including shared memory mappings IIRC). This leaves the heap and program executable.

I believe the Fedora/RedHat kernels randomize the heap base, but not executables (even PIEs, see bug #139435). PaX definitely randomizes the heap base, and can randomize the base of PIEs (as well as non-PIEs in some cases using complex segmentation tricks).

I believe it would be advantageous security-wise to ship kernels that can randomize the heap base. This may require some politics on the LKML or simply shipping with some custom patches; also for compatibility, a boot-time switch to disable heap randomization should be available.

It would also be advantageous to randomize the base of PIEs in the context of bug #139435, for the reasons given there.

[Kees Cook (kees)]

Yes, this is where we're heading. I've been working with some of the SuSE engineers to test and prepare patches[1] for LKML. For other details and a test tool, see bug 83895.

[Kees Cook (kees)]

Sorry, forgot lkml pointers:

http://lkml.org/lkml/2007/8/8/221
http://lkml.org/lkml/2007/8/22/254

[Stephen Cook (siti)]

I marked the bug as duplicate. It's a similar bug to #139435. On jaunty, I believe intrepid introduced it (via linux kernel upgrade) all memory maps are randomized apart from the executable (unless PIE which very few things are) and vsyscall.

Example 1:
00400000-00408000 r-xp 00000000 08:15 5824608 /bin/cat
00607000-00608000 r--p 00007000 08:15 5824608 /bin/cat
00608000-00609000 rw-p 00008000 08:15 5824608 /bin/cat
01a92000-01ab3000 rw-p 01a92000 00:00 0 [heap]
7f4b6f56e000-7f4b6f6d6000 r-xp 00000000 08:15 3039422 /lib/libc-2.9.so
7f4b6f6d6000-7f4b6f8d6000 ---p 00168000 08:15 3039422 /lib/libc-2.9.so
7f4b6f8d6000-7f4b6f8da000 r--p 00168000 08:15 3039422 /lib/libc-2.9.so
7f4b6f8da000-7f4b6f8db000 rw-p 0016c000 08:15 3039422 /lib/libc-2.9.so
7f4b6f8db000-7f4b6f8e0000 rw-p 7f4b6f8db000 00:00 0
7f4b6f8e0000-7f4b6f900000 r-xp 00000000 08:15 3039248 /lib/ld-2.9.so
7f4b6f9b5000-7f4b6f9f4000 r--p 00000000 08:15 5185537 /usr/lib/locale/en_NZ.utf8/LC_CTYPE
7f4b6f9f4000-7f4b6fadf000 r--p 00000000 08:15 5185539 /usr/lib/locale/en_NZ.utf8/LC_COLLATE
7f4b6fadf000-7f4b6fae1000 rw-p 7f4b6fadf000 00:00 0
7f4b6faeb000-7f4b6faec000 r--p 00000000 08:15 5472564 /usr/lib/locale/en_NZ.utf8/LC_NUMERIC
7f4b6faec000-7f4b6faed000 r--p 00000000 08:15 5185538 /usr/lib/locale/en_NZ.utf8/LC_TIME
7f4b6faed000-7f4b6faee000 r--p 00000000 08:15 5472317 /usr/lib/locale/en_NZ.utf8/LC_MONETARY
7f4b6faee000-7f4b6faef000 r--p 00000000 08:15 5472568 /usr/lib/locale/en_NZ.utf8/LC_MESSAGES/SYS_LC_MESSAGES
7f4b6faef000-7f4b6faf0000 r--p 00000000 08:15 5472565 /usr/lib/locale/en_NZ.utf8/LC_PAPER
7f4b6faf0000-7f4b6faf1000 r--p 00000000 08:15 5472563 /usr/lib/locale/en_NZ.utf8/LC_NAME
7f4b6faf1000-7f4b6faf2000 r--p 00000000 08:15 5472318 /usr/lib/locale/en_NZ.utf8/LC_ADDRESS
7f4b6faf2000-7f4b6faf3000 r--p 00000000 08:15 5472319 /usr/lib/locale/en_NZ.utf8/LC_TELEPHONE
7f4b6faf3000-7f4b6faf4000 r--p 00000000 08:15 5472561 /usr/lib/locale/en_NZ.utf8/LC_MEASUREMENT
7f4b6faf4000-7f4b6fafb000 r--s 00000000 08:15 5455999 /usr/lib/gconv/gconv-modules.cache
7f4b6fafb000-7f4b6fafc000 r--p 00000000 08:15 5472320 /usr/lib/locale/en_NZ.utf8/LC_IDENTIFICATION
7f4b6fafc000-7f4b6faff000 rw-p 7f4b6fafc000 00:00 0
7f4b6faff000-7f4b6fb00000 r--p 0001f000 08:15 3039248 /lib/ld-2.9.so
7f4b6fb00000-7f4b6fb01000 rw-p 00020000 08:15 3039248 /lib/ld-2.9.so
7fff77aec000-7fff77b01000 rw-p 7ffffffea000 00:00 0 [stack]
7fff77bff000-7fff77c00000 r-xp 7fff77bff000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]

Example 2:
00400000-00408000 r-xp 00000000 08:15 5824608 /bin/cat
00607000-00608000 r--p 00007000 08...

[Kees Cook (kees)]

This was finished in Hardy (8.04).