Conversation

Replying to and
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
Replying to and
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
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
Ttheir policies permit you to download and execute arbitrary content in the Safari WebView. If you ship a Python interpreter and then you download Python code from your servers to run, that's a violation of the rules. If you run only Python included in the app, that's fine.
1
The Play Store has a directly comparable rule. The reason for the rules is that they want to be able to review all of the code. If they allow you to dynamically download and execute code, they can't review all of it, so they will ban apps caught doing that. Safari is a loophole.
1
Show replies