3 ms·

Short answer: more or less, yes. Caveat, Google, Mozilla and Microsoft each have differing WA implementations. For Chrome, WebAssembly gets fed into the V8 Tur

Short answer: more or less, yes. Caveat, Google, Mozilla and Microsoft each have differing WA implementations. For Chrome, WebAssembly gets fed into the V8 TurboFan JIT: https://ia601208.us.archive.org/16/items/vmss16/titzer.pdf https://ia601208.us.archive.org/16/items/vmss16/titzer.pdf JITs are a security hole. In particular, Apple won't allow your JIT on their iOS. They've only just recently allowed you to use their Core JIT on iOS: https://www.blackhat.com/docs/us-16/materials/us-16-Krstic.pdf https://www.blackhat.com/docs/us-16/materials/us-16-Krstic.p... What you can do to Turbofan inside of the Chrome sandbox, you could probably do with WA.

geofft 10y ago
iOS's security concerns about JITs aren't general-purpose. They only apply in the weird security model that Apple has set up for themselves. The fundamental security challenge of iOS is that there exist things called "private APIs" - Apple-authored code that lives in the address space of a developer's application that the developer is not permitted to call directly. It exists so that "public APIs," a different set of Apple-authored code that is technically indistinguishable from private APIs (mapped in the same way, with the same memory protection, etc.), can use the private APIs in their implementation, and so that developers can call public APIs in turn. In order to enforce this, Apple does static analysis and manual inspection of binaries uploaded to the App Store, and signs every page of executable code that can execute on an iOS device. (It's not very good static analysis. I've had an app rejected because it used a third-party framework that happened to share a symbol name with a private API, and I've had an app accepted and shipped that, at runtime, disassembled the code of a public API to find the offset of a private API, and did questionable things to the private API's static local variables.) The ability of the app to generate code at runtime would completely defeat Apple's ability to do static analysis or manual review worth anything. It could, for instance, download a function from the developer's website and then execute it. For this reason, Apple has technical means to prevent you from running code that it did not sign. As a side effect, this prevents you from implementing a JIT. The attacks described in that Black Hat presentation you link are about gaining "arbitrary code execution" with the permissions of the app, no more. In any other OS design, this isn't an exploit, this is how apps work. If you download a Windows .exe and run it, the .exe gets to supply arbitrary native code. If you download an Android .apk and run it, the .apk gets to supply arbitrary native code. If you go to a website, the website gets to supply arbitrary JavaScript (though not native code). Nobody is reviewing that JavaScript to figure out what it does; the JavaScript simply executes on a platform that restricts the abilities of all possible JS. That's how application distribution works. Apple has chosen this very different model on iOS where apps are reviewed in advance to limit what code can run; under that model, being able to run arbitrary code is an exploit. But that doesn't mean that JITs, which necessarily require being able to run arbitrary code, are a security hole under any other model.
- comex 10y ago
  This is incorrect. I've talked to Apple security people, and interned there a few years ago. They're not that dumb; they know that it's trivial to get around the private API check, and private APIs are never intentionally used to enforce a security boundary (that's what XPC is for). Apple doesn't want you calling private APIs for a variety of reasons, but those reasons aren't connected either with security or with the JIT prohibition. It's perfectly permissible under App Store rules to use an interpreter which is functionally equivalent to a JIT in its ability to obfuscate code, or invoke or manipulate private APIs (e.g. can read/write arbitrary addresses, run dlsym, whatever). You aren't allowed to download bytecode for that interpreter from the internet, but again, that's a policy restriction, not a technical one.
  - geofft 10y ago
    Yeah, I think by calling this a "security model" I was simultaneously too generous and too insulting. :) There is definitely a team of smart people at Apple that design the OS / kernel to be secure against apps that are allowed to run arbitrary code; this is where stuff like kernel sandboxing comes from. There is also a team at Apple that tries to prevent apps from running arbitrary code, and does an okay job of it. (I assume this team is also populated by smart people, and they know that they're not actually implementing a foolproof security restriction, they're implementing a policy restriction.) The ban on JITs, as I understand it, comes from the second team. There's no actual threat to iOS device security from allowing apps to run custom, arbitrary native code, right?
    - DerekL 10y ago
      > There's no actual threat to iOS device security from allowing apps to run custom, arbitrary native code, right? An app might have a buffer overflow bug. Allowing all or some of the writable memory to be executable makes it easier for an attacker to exploit such a bug. (An attacker can still exploit the bug without arbitrary native code execution, but it's harder.) The apps are still protected from one another, so this restriction mainly protects app developers from their own mistakes.

geofft 10y ago

iOS's security concerns about JITs aren't general-purpose. They only apply in the weird security model that Apple has set up for themselves. The fundamental security challenge of iOS is that there exist things called "private APIs" - Apple-authored code that lives in the address space of a developer's application that the developer is not permitted to call directly. It exists so that "public APIs," a different set of Apple-authored code that is technically indistinguishable from private APIs (mapped in the same way, with the same memory protection, etc.), can use the private APIs in their implementation, and so that developers can call public APIs in turn. In order to enforce this, Apple does static analysis and manual inspection of binaries uploaded to the App Store, and signs every page of executable code that can execute on an iOS device. (It's not very good static analysis. I've had an app rejected because it used a third-party framework that happened to share a symbol name with a private API, and I've had an app accepted and shipped that, at runtime, disassembled the code of a public API to find the offset of a private API, and did questionable things to the private API's static local variables.) The ability of the app to generate code at runtime would completely defeat Apple's ability to do static analysis or manual review worth anything. It could, for instance, download a function from the developer's website and then execute it. For this reason, Apple has technical means to prevent you from running code that it did not sign. As a side effect, this prevents you from implementing a JIT. The attacks described in that Black Hat presentation you link are about gaining "arbitrary code execution" with the permissions of the app, no more. In any other OS design, this isn't an exploit, this is how apps work. If you download a Windows .exe and run it, the .exe gets to supply arbitrary native code. If you download an Android .apk and run it, the .apk gets to supply arbitrary native code. If you go to a website, the website gets to supply arbitrary JavaScript (though not native code). Nobody is reviewing that JavaScript to figure out what it does; the JavaScript simply executes on a platform that restricts the abilities of all possible JS. That's how application distribution works. Apple has chosen this very different model on iOS where apps are reviewed in advance to limit what code can run; under that model, being able to run arbitrary code is an exploit. But that doesn't mean that JITs, which necessarily require being able to run arbitrary code, are a security hole under any other model.

comex 10y ago
This is incorrect. I've talked to Apple security people, and interned there a few years ago. They're not that dumb; they know that it's trivial to get around the private API check, and private APIs are never intentionally used to enforce a security boundary (that's what XPC is for). Apple doesn't want you calling private APIs for a variety of reasons, but those reasons aren't connected either with security or with the JIT prohibition. It's perfectly permissible under App Store rules to use an interpreter which is functionally equivalent to a JIT in its ability to obfuscate code, or invoke or manipulate private APIs (e.g. can read/write arbitrary addresses, run dlsym, whatever). You aren't allowed to download bytecode for that interpreter from the internet, but again, that's a policy restriction, not a technical one.
- geofft 10y ago
  Yeah, I think by calling this a "security model" I was simultaneously too generous and too insulting. :) There is definitely a team of smart people at Apple that design the OS / kernel to be secure against apps that are allowed to run arbitrary code; this is where stuff like kernel sandboxing comes from. There is also a team at Apple that tries to prevent apps from running arbitrary code, and does an okay job of it. (I assume this team is also populated by smart people, and they know that they're not actually implementing a foolproof security restriction, they're implementing a policy restriction.) The ban on JITs, as I understand it, comes from the second team. There's no actual threat to iOS device security from allowing apps to run custom, arbitrary native code, right?
  - DerekL 10y ago
    > There's no actual threat to iOS device security from allowing apps to run custom, arbitrary native code, right? An app might have a buffer overflow bug. Allowing all or some of the writable memory to be executable makes it easier for an attacker to exploit such a bug. (An attacker can still exploit the bug without arbitrary native code execution, but it's harder.) The apps are still protected from one another, so this restriction mainly protects app developers from their own mistakes.