1. 21
  1.  

  2. 3

    I understand the other protections but… what’s the immutable userland mappings protecting against?

    1. 3

      Usually one of the first steps in a ROP chain is to call mprotect to make some memory region suitable for shellcode. I guess it’s to make that harder?

      1. 3

        From Theo’s original email:

        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?