I’m aware of an method used at least once (not on openbsd) which managed
to mprotect a region of libc, and then place things there, for later
execution. That makes msyscall() less useful, so I want to restore the
strenth.
From what I can gather: msyscall()was introduced, so shellcode wouldn’t be able to syscall without going through the libc, which would require breaking ASLR. However, currently (or at least as of 2019) all of .text can syscall too, so shellcode could instead modify .text and place the syscall traps there. mimmutable() would prevent that, by making all the code that can syscall read-only.
I don’t understand what Theo meant in that email, though. If you can mprotect part of the libc, this implies that you know its address - so msyscall would be useless anyways, right?
I understand the other protections but… what’s the immutable userland mappings protecting against?
Usually one of the first steps in a ROP chain is to call
mprotectto make some memory region suitable for shellcode. I guess it’s to make that harder?From Theo’s original email:
From what I can gather:
msyscall()was introduced, so shellcode wouldn’t be able to syscall without going through the libc, which would require breaking ASLR. However, currently (or at least as of 2019) all of .text can syscall too, so shellcode could instead modify .text and place the syscall traps there.mimmutable()would prevent that, by making all the code that can syscall read-only.I don’t understand what Theo meant in that email, though. If you can
mprotectpart of the libc, this implies that you know its address - somsyscallwould be useless anyways, right?