7 ms·

I haven't really looked into the implementation, but won't this be yet another possible way for getting out of the V8 sandbox and be able to execute code and th

I haven't really looked into the implementation, but won't this be yet another possible way for getting out of the V8 sandbox and be able to execute code and thus be able to exploit? I recall exploits using typed arrays for code execution before, because they can contain raw assembly in a very low-level style (e.g a plain char array in C++)...

littlegreenb18 10y ago
This is not machine assembly. Its bytecode, everything still lives in the browser sandbox.
- deleted 10y ago
  [deleted]
- chillydawg 10y ago
  Where the sandbox now has a much larger attack surface as it has to implement a whole new virtual machine to run the webasm.
  - gsnedders 10y ago
    Nobody's writing a whole new VM to run it; everyone is just treating it as another input format to their JS VM.
    - icefox 10y ago
      https://github.com/AndrewScheidecker/WAVM https://github.com/AndrewScheidecker/WAVM
      - gsnedders 10y ago
        Given the context, what browser is that going into? How is that relevant to browser sandboxing?
        icefox 10y ago
        Ah yes within the browser space the various companies are just putting web assembly in/alongside the existing javascript engines. WAVM was just an example of a whole new vm that isn't for a browser, but does run webassembly.
        gsnedders 10y ago
        Yeah; I probably should've been more explicit in my original comment: there's definitely new VMs being written for WASM, but none are currently expecting to go into browsers, hence concerns about sandbox escapes from browsers aren't affected by them.
- hinkley 10y ago
  There were bugs in the Java VM that were only surfaced by people writing tools that generated java assembly. It's probably safest to assume that history will more or less repeat itself with web assembly.
deleted 10y ago
[deleted]
CalChris 10y ago
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.

littlegreenb18 10y ago

This is not machine assembly. Its bytecode, everything still lives in the browser sandbox.

deleted 10y ago
[deleted]
chillydawg 10y ago
Where the sandbox now has a much larger attack surface as it has to implement a whole new virtual machine to run the webasm.
- gsnedders 10y ago
  Nobody's writing a whole new VM to run it; everyone is just treating it as another input format to their JS VM.
  - icefox 10y ago
    https://github.com/AndrewScheidecker/WAVM https://github.com/AndrewScheidecker/WAVM
    - gsnedders 10y ago
      Given the context, what browser is that going into? How is that relevant to browser sandboxing?
      - icefox 10y ago
        Ah yes within the browser space the various companies are just putting web assembly in/alongside the existing javascript engines. WAVM was just an example of a whole new vm that isn't for a browser, but does run webassembly.
        gsnedders 10y ago
        Yeah; I probably should've been more explicit in my original comment: there's definitely new VMs being written for WASM, but none are currently expecting to go into browsers, hence concerns about sandbox escapes from browsers aren't affected by them.
hinkley 10y ago
There were bugs in the Java VM that were only surfaced by people writing tools that generated java assembly. It's probably safest to assume that history will more or less repeat itself with web assembly.

deleted 10y ago

[deleted]

CalChris 10y ago

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.