daemon2k wrote:If "Introducing code into a task's address space is possible by either creating an executable mapping or modifying an already existing writable/executable mapping" and MPROTECT prevents you from
- creating executable anonymous mappings
- creating executable/writable file mappings
- making an executable/read-only file mapping writable except for performing relocations on an ET_DYN ELF file (non-PIC shared library)
- making a non-executable mapping executable
then does not MPROTECT prevent this first venue of attack (along with NOEXEC preventing the second venue)?
no, there are still two more ways left with the above active.
1. there's an exception in MPROTECT itself that allows ELF text relocations to work, that means that userland can turn an executable file mapping to be writable then executable again, this can effectively introduce code into the address space. unfortunately in real-life systems not everything (mainly libraries, but i've seen plain executables as well on some architectures) is text relocation free, so unless your system is specifically created this way, you can't remove this exception (NOELFRELOCS is the feature that does this enforcement, Adamantix is using it for example).
2. even with MPROTECT and NOELFRELOCS on there's a way to have the attacked task create/open, write to and mmap a file, that will also introduce new code. of course there're several ways to break this chain of events but that has nothing to do with memory protection per se, but rather good old file system permissions and access control.
