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?
Conversation
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
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.
There are a lot of things that are not actually prevented at a technical level but rather are simply forbidden by App Store policy. A surprising amount of privacy restrictions such as not detecting other apps on the system are incomplete at a technical level and rely on policy.
1
I guess you mean on iOS; it's definitely real on Android. Why isn't interpreter permitted by policies if the interpreter does not expose any access to system facilities?
2
Like, as a really stupid exercise, you could compile Firefox (or at least a non-bloated browser) to wasm and run the whole thing inside a tab in their Safari junk to get a real browser on iOS... So why can't you just do that with an app?
1
Show replies