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!
Conversation
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.
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.
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
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.
How does Firefox on iOS work? Is it just a fake Firefox that's reskinned Safari widget with some Firefox features on top, or do they just use interp-only? (The latter would be *extremely* preferable no matter how slow it is.)
1
Chrome and Firefox on Android are skins over top of a Safari widget. Apple's policies forbid shipping any alternative web engine implementation. An interpreter-only approach would work at a technical level but isn't permitted by their App Store policies. This is common for them.
2
1
Show replies