22

I have just noticed that my simple program has its data and stack segments executable. I saw it in /proc/[pid]/maps, and simple code confirmed it.

For example:

; prog.asm
section .data
    code:   db 0xCC    ;int3

section .text
global _start
_start:
    jmp    code

    mov    rax, 60    ; sys_exit
    mov    rdi, 0
    syscall

then

nasm -f elf64 prog.asm
ld -o prog prog.o
./prog

causes prog to execute int3 instruction.

Programs written in C and built with gcc have their data, stack and heap non-executable, so why those written in assembly behave in a different manner?

witosx
  • 614
  • 4
  • 15

1 Answers1

23

On modern Linux systems, the linker will mark stack/data non-executable IFF all objects that participate in the link have a special "marker" section .note.GNU-stack.

If you compile e.g. int foo() { return 1; } into assembly (with gcc -S foo.c), you'll see this:

    .section    .note.GNU-stack,"",@progbits

For nasm, the syntax is shown in section 8.9.2 of the manual; you want something like this:

 section .note.GNU-stack noalloc noexec nowrite progbits

Note

This has to be done for every .o file that goes into the executable. If any object file needs executable stack or data, then it's set for the entire segment.

Marco
  • 2,796
  • 19
  • 24
Employed Russian
  • 199,314
  • 34
  • 295
  • 362
  • It works, thanks. Btw, I found this: [link](http://www.nasm.us/doc/nasmdoc7.html), and in section 7.9.2 "elf Extensions to the SECTION Directive" there is statement that section .data by default has noexec flag. But even writing noexec explicitly in code with section .data doesn't work. Strange. – witosx Oct 23 '11 at 12:27
  • 1
    Could you provide any source that documents the `GNU_STACK` behavior? I have seen that you can pass `-z noexecstack` to `ld` for it to have the same behavior... But isn't this a loader problem? the loader is mapping the .data section as executable when it clearly is marked as noexec. – Marco Jul 26 '20 at 23:44
  • 2
    @Marco: slightly more info at [Unexpected exec permission from mmap when assembly files included in the project](https://stackoverflow.com/q/58260465), including a link to the Linux kernel source. – Peter Cordes Jul 26 '20 at 23:56
  • Thanks. That provides some clarity. I think I understand the rationale of it: old elfs (before NX bit in modern archs), might depend on having executable data, as there was no way to disable it. So in order to detect "newer" elfs, the loader uses the executable stack feature. It's sad that `nasm` doesn't have a flag to add that automatically. – Marco Jul 27 '20 at 00:47
  • 2
    Note that the behavior [recently changed](https://lore.kernel.org/kernel-hardening/20200327064820.12602-1-keescook@chromium.org/) for the linux kernel. With newer kernels the sections compiled with `nasm` will no longer be executable by default in x86_64. [See commit](https://github.com/torvalds/linux/commit/9fccc5c0c99f238aa1b0460fccbdb30a887e7036) – Marco Jul 27 '20 at 06:22