Linux and no-exec heap (-z,noexecheap)

[Jeffrey Walton]

Hi All,

I need to test some code that uses no-exec heaps.

I know I can get nx-heaps from BSD and Gentoo. Neither are install friendly (base + window manager), so I'm looking for a Linux that is:

1) easy to install (ISO, LiveCD)
2) has a window/desktop manager
3) has no-exec heaps

I'm not trying to learn a new variant of *nix - I just need to test some code against no-exec heaps.

Any suggestions for a distro to load up in a VM?

Jeff

[John Reiser]

> I need to test some code that uses no-exec heaps.

Fedora 17 says that by default there is no eXecute permission on [heap]:
-----
$ cat /proc/self/maps
00400000-0040b000 r-xp 00000000 08:0c 400228 /usr/bin/cat
0060a000-0060b000 r--p 0000a000 08:0c 400228 /usr/bin/cat
0060b000-0060c000 rw-p 0000b000 08:0c 400228 /usr/bin/cat

021c4000-021e5000 rw-p 00000000 00:00 0 [heap] <<< look here

37d4200000-37d4220000 r-xp 00000000 08:0c 397004 /usr/lib64/ld-2.15.so
37d441f000-37d4420000 r--p 0001f000 08:0c 397004 /usr/lib64/ld-2.15.so
37d4420000-37d4421000 rw-p 00020000 08:0c 397004 /usr/lib64/ld-2.15.so
37d4421000-37d4422000 rw-p 00000000 00:00 0
37d4600000-37d47ac000 r-xp 00000000 08:0c 399164 /usr/lib64/libc-2.15.so
37d47ac000-37d49ac000 ---p 001ac000 08:0c 399164 /usr/lib64/libc-2.15.so
37d49ac000-37d49b0000 r--p 001ac000 08:0c 399164 /usr/lib64/libc-2.15.so
37d49b0000-37d49b2000 rw-p 001b0000 08:0c 399164 /usr/lib64/libc-2.15.so
37d49b2000-37d49b7000 rw-p 00000000 00:00 0
7f04ccf32000-7f04d335f000 r--p 00000000 08:0c 412757 /usr/lib/locale/locale-archive
7f04d335f000-7f04d3362000 rw-p 00000000 00:00 0
7f04d3379000-7f04d337a000 rw-p 00000000 00:00 0
7fff83a32000-7fff83a53000 rw-p 00000000 00:00 0 [stack]
7fff83b09000-7fff83b0a000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
-----

If that is not good enough, then build what you want.
However, recent build tools lack such an option:
-----
$ gcc -Wl,-z,noexecheap -g -o hello hello.c
/usr/bin/ld: warning: -z noexecheap ignored.
$ /usr/bin/ld --version
GNU ld version 2.22.52.0.1-10.fc17 20120131
$ info ld
/noexecheap
>>Search failed.
-----

--

[Jeffrey Walton]

Thanks John. I recall reading that too (http://lists.fedoraproject.org/
pipermail/devel-announce/2011-August/000821.html). It was planned for
Fedora 16.

When I tried to compile on Fedora 17 with -Wl,-z,noexecheap, I got a
complaint from LD. (Fedora 16/17 was my original choice for
demonstration purposes).

> 021c4000-021e5000 rw-p 00000000 00:00 0

Just to avoid misunderstandings: 'rw-p' lacks 'x', and that's what I
am looking for. On disk, I'm looking for the GNU_HEAP *with* a 0 size
and no 'X':

readelf -l demo.exe | grep -i "GNU_HEAP"

Type Offset VirtAddr PhysAddr FileSize MemSize Flg Align
GNU_HEAP 0x000000 0x00000000 0x00000000 0x000000 0x000000 RW 0x04

I'm not sure why verification includes a 0-size into the requirement,
but I think it has to do with consistency: previous handling of
stacks, GCC nested functions, and trampolines.

Is there a system parameter I can read from /proc/sys/kernel/ to
verify the platform configuration?

Jeff

[John Reiser]

>> 021c4000-021e5000 rw-p 00000000 00:00 0
> Just to avoid misunderstandings: 'rw-p' lacks 'x', and that's what I
> am looking for. On disk, I'm looking for the GNU_HEAP *with* a 0 size
> and no 'X':
>
> readelf -l demo.exe | grep -i "GNU_HEAP"
>
> Type Offset VirtAddr PhysAddr FileSize MemSize Flg Align
> GNU_HEAP 0x000000 0x00000000 0x00000000 0x000000 0x000000 RW 0x04

On Fedora 17 the default build procedures do not generate such a[ PT_]GNU_HEAP.
In fact, there is no such symbol in /usr/include/elf.h:
-----
$ rpm -qf /usr/include/elf.h
glibc-headers-2.15-51.fc17.x86_64
$ grep HEAP /usr/include/elf.h
$ ### *empty* result
$ readelf --segments ./hello

Elf file type is EXEC (Executable file)
Entry point 0x4003d0
There are 8 program headers, starting at offset 64

Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
PHDR 0x0000000000000040 0x0000000000400040 0x0000000000400040
0x00000000000001c0 0x00000000000001c0 R E 8
INTERP 0x0000000000000200 0x0000000000400200 0x0000000000400200
0x000000000000001c 0x000000000000001c R 1
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000
0x000000000000a2e4 0x000000000000a2e4 R E 200000
LOAD 0x000000000000a2e8 0x000000000060a2e8 0x000000000060a2e8
0x000000000000021c 0x0000000000000220 RW 200000
DYNAMIC 0x000000000000a300 0x000000000060a300 0x000000000060a300
0x00000000000001d0 0x00000000000001d0 RW 8
NOTE 0x000000000000021c 0x000000000040021c 0x000000000040021c
0x0000000000000044 0x0000000000000044 R 4
GNU_EH_FRAME 0x000000000000a210 0x000000000040a210 0x000000000040a210
0x000000000000002c 0x000000000000002c R 4
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 8

Section to Segment mapping:
Segment Sections...
00
01 .interp
02 .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata .eh_frame_hdr .eh_frame
03 .init_array .fini_array .jcr .dynamic .got .got.plt .data .bss
04 .dynamic
05 .note.ABI-tag .note.gnu.build-id
06 .eh_frame_hdr
07
-----

>
> I'm not sure why verification includes a 0-size into the requirement,

What is this "verification" of which you speak?

> but I think it has to do with consistency: previous handling of
> stacks, GCC nested functions, and trampolines.
>
> Is there a system parameter I can read from /proc/sys/kernel/ to
> verify the platform configuration?

The .config is not compiled into the running kernel.
Instead, the default installation procedure puts a copy in /boot:
-----
$ cd /boot
$ ls -l config-3.5.0-2.fc17.x86_64 vmlinuz-3.5.0-2.fc17.x86_64
-rw-r--r--. 1 root root 118625 Jul 30 08:05 config-3.5.0-2.fc17.x86_64
-rwxr-xr-x. 1 root root 4772672 Jul 30 08:05 vmlinuz-3.5.0-2.fc17.x86_64
-----

--

[Richard Kettlewell]

John Reiser <jrei...@comcast.net> writes:

>> I need to test some code that uses no-exec heaps.
>
> Fedora 17 says that by default there is no eXecute permission on
> [heap]:

That only tells you the permissions recorded by the kernel for that
mapping; it doesn't tell you whether they are actually enforced, and you
will find that on some platforms they are not. The best approach is to
write a small test program.

(Also, [heap] is not the whole heap, but that's not likely to make much
difference to the outcome here.)

--
http://www.greenend.org.uk/rjk/

[Jeffrey Walton]

On Aug 12, 10:52 pm, John Reiser <jreise...@comcast.net> wrote:
> >> 021c4000-021e5000 rw-p 00000000 00:00 0
> > Just to avoid misunderstandings: 'rw-p' lacks 'x', and that's what I
> > am looking for. On disk, I'm looking for the GNU_HEAP *with* a 0 size
> > and no 'X':
>
> >     readelf -l demo.exe | grep -i "GNU_HEAP"
>
> > Type       Offset   VirtAddr   PhysAddr   FileSize  MemSize Flg  Align
> > GNU_HEAP   0x000000 0x00000000 0x00000000 0x000000 0x000000  RW  0x04
>
> On Fedora 17 the default build procedures do not generate such a[ PT_]GNU_HEAP.
> In fact, there is no such symbol in /usr/include/elf.h:
> -----
> $ rpm -qf /usr/include/elf.h
> glibc-headers-2.15-51.fc17.x86_64
> $ grep HEAP /usr/include/elf.h
> $     ### *empty* result
> $ readelf --segments ./hello
>
> Elf file type is EXEC (Executable file)
> Entry point 0x4003d0
> There are 8 program headers, starting at offset 64
>

> [SNIP]

>
> > I'm not sure why verification includes a 0-size into the requirement,
>
> What is this "verification" of which you speak?

A manual audit to ensure the binary has the proper markings.

"Markings" could be the next source of confusion, but it means
whatever mechanism the platform is using. For example, -z,noexecstack
will generate a GNU_STACK section with a 0 size (http://www.airs.com/
blog/archives/518). Colloquially, I refer to the binary as being
marked with no-exec stacks.

Jeff