mseal() and what comes after

Posted Oct 24, 2023 3:37 UTC (Tue) by calumapplepie (guest, #143655)
In reply to: mseal() and what comes after by randomguy3
Parent article: mseal() and what comes after

How about we add a new flag on binaries, GNU_STACK_FORBID, which says "I solemnly swear that this program won't open anything with a GNU_STACK". Distributions can globally enable the flag on all their binaries, allowing ld.so to apply immutability to the stack.

Similar things can be done for other OpenBSD protections. Stuff like RAW_SYSCALL_FORBID (to block syscalls outside of libc), or a new section that declares what sections of the desired memory map are the stack to allow for the pointer protection. For most programs, the compiler knows where the stack is, and for the exceptions, distributors can remove the flags from binaries. Existing programs would obviously lack the flags, and just keep working.

to post comments

mseal() and what comes after

Posted Oct 24, 2023 11:54 UTC (Tue) by dullfire (guest, #111432) [Link]

So a note: The presence of a GNU_STACK section allows ld.so to possibly NOT mark the stack as executable. If the header is missing ld.so will be forced to mark the stack as executable. So forbidding loading anything will defiantly not achieve the desired results.

Additional certain gcc nested functions require stack trampolines (and thus an executable stack). I don't know about the prevalence of this feature, especially in shared libs. However an "GNU_STACK_FORBID" would have to be a compile time opt-in thing (since you could not know if it is actually needed until runtime).

Finally, the compiler will have no clue where the stack is. Address space layout randomization means it could be basically anywhere. Additionally, there's[1] 1 stack per thread, but the thread number is runtime determined. So even if ASLR was disabled, and GNU_STACK (or another mechanism added) was extended to allow specifying the stack address (AFAIK it does not currently allow this), only single threaded programs would have "compile time" knowledge of the stack address.

That said: a GNU_STACK_MASK might be a good idea. Basically a mask of disallow permission on the stack. Any attempt to dlopen() a library that would violate the mask could return an error, and a load time ld.so attempt to violate a programs mask could just throw an error and exist before main().

[1] Actually there are good reasons to have multiple stacks per thread. One of them is a SIGSEGV handler, which requires a separate stack. Another, though rare, is any attempt to use any form of userland threading.