Conversation

When the inevitable ARM macintosh comes out, do you think Apple will allow W+X pages on it or do you think they'll impose W^X and call it a "security feature"
4
28
Replying to and
A strong implementation prevents dynamic code generation. On Linux, this is provided by SELinux. If a process doesn't have the execmem permission, it can't create W|X mappings or transition mappings that were writable to executable, including not being able to do rw -> r -> rx.
2
Replying to
Can you speak more to the cases where preventing the use of execmem is an improvement to security? Thinking maybe a situation where a vuln doesn't enable full RCE through some *OP variant, but allows enough memory corruption to change the flag to mprotect, and jmp to WX mem?
2
Replying to
It's useful in more than one situation. It remains useful even once the attacker has gained 'arbitrary' code execution. The next step is to escape from the sandbox, and it hurts if they can only use the existing native code by modifying function pointers / return addresses.
1
Replying to and
They can't set up system calls however they want or use arbitrary architectural functionality in ways not implemented by the existing code. Immutable mappings are a standard security feature adding to this too, especially combined with type-based CFI. It reduces attack surface.
1
Replying to and
Enforcing it for files prevents classes of vulnerabilities where the attacker tricks the code into executing attacker data. Very useful to enforce that any potentially writable files on storage cannot be executed. Similar to the benefits of a good Content-Security-Policy for JS.
1
1
Replying to and
Consider software with support for loading plugins dynamically. This is often done via native libraries. Tricking these systems into running the attacker's data is one of the most common forms of RCE not involving memory corruption. May or may not involve file write bugs.
1
Show replies