There is a difference between code reuse and arbitrary code exec, despite the line being blurred by academic distractions of Turing completeness
Conversation
Replying to
Quite possibly yes, was living in a cave, missed stuff. Are there in the wild exploits that care to use ROP to VirtualProtect/mprotect and then use shellcode, rather than ROP all along? Since you mention VirtualProtect, maybe that's more lucrative and common on Windows? Thanks!
1
Yes. This was absolutely the case, though I don't have links handy. The reason is obvious--why do more work than necessary? Among people I know who write exploits their first ROP was almost always "get my shellcode running" versus a full payload until that technique died.
1
1
Makes sense. I guess for local shell exec I'd just ROP, but e.g. for a connect back shell it does feel like less work and more reliable to get a shellcode running. By "that technique died", do you mean Windows hardening VirtualProtect in a way similar to PaX MPROTECT?
1
I was specifically thinking of code-signing on iOS forcing all payloads to be full ROP.
2
How does code-signing achieve that given the payload would only appear as code in an already running and perhaps already verified program? I'd expect the actually relevant change to be similar to PaX MPROTECT, no?
1
Code signing means I can no longer mark my shellcode as executable because that page isn't signed. It's physically impossible to execute attacker controlled raw shellcode. You can do JIT abuse, interp attacks, etc, but not native opcodes.
2
1
Ah, per-page signing with signature checked on mprotect? That's interesting. I didn't know they had that.
1
1
Not checked on mprotect. Literally just checked on execution. All code must be signed. Period.
2
1
That's even more interesting. How do you check signature on execution? Have the page non-executable up to and including the point of transferring control to it, and do the signature check from the page fault handler?
2
It's essentially MPROTECT combined with checking the signature of pages faulted in via memory mappings.
Permitting only code loaded from the verified images would be stricter, but they need to permit user-installed apps. They require that Apple has signed all the code pages.
This is part of what people mean when they talk about code signing on iOS. Safari has a special exception allowing it to bypass this for the JavaScript JIT compiler and Safari is the only permitted browser engine. Apps are allowed to ship powerful interpreters and blur the lines.
2
1
Dynamic code execution either via memory or storage can be disallowed without a comparable feature. Looking at it as an exploit mitigation is missing the point. Enforced code signing is an extension of verified boot beyond the OS. It's primarily an anti-persistence feature.
2
Show replies