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.
Conversation
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.
1
3
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.
It enforces that all native code running on the device is signed by Apple. So, compared to MPROTECT + blocking execution of app data it prevents an attacker from persisting access through setting up a custom app and granting it all of the possible dynamically granted permissions.
Somewhat agree on anti-persistence. Anti-persistence just means you need a local config parser bug instead though. 😉
My invoking of code signing was just that it came up in the context of ROP to memprotect versus full payload rop and why full ROP harder.
1
And to be fair, local config parser bug is much harder in the face of full code signing, but this just goes right back to the original discussion that kicked this all off. :-)