4 ms·

You missed the author's point by miles. C only has access to its process space as does WASM. WASM's only improvement is it makes stack smashing bugs harder (wh

You missed the author's point by miles. C only has access to its process space as does WASM. WASM's only improvement is it makes stack smashing bugs harder (which ironically makes real security worse as it means you can't use retpoline, but let's ignore that for now) HOWEVER it gives up on using guard pages and address randomization (systemic preventions against common bugs like buffer overflows), making WASM in practice less safe than C. WASM is only safer for the host embedding untrusted code. For trusted code, though, it's across the board worse in every way - including security. Which shouldn't be all that contentious of a statement since WASM had no goals or intentions to ever replace trusted native code execution. That's not a thing it tries to do, and it shouldn't be a surprise that it didn't do it.

monocasa 8y ago
> which ironically makes real security worse as it means you can't use retpoline Why wouldn't the WASM JIT retpoline all code (probably only if the underlying processor needs it) rather than relying on the guest programs to do it themselves. > HOWEVER it gives up on using guard pages and address randomization (systemic preventions against common bugs like buffer overflows), making WASM in practice less safe than C. Once again, wouldn't the JIT be able to enforce this at runtime? It's not like WASM binaries are referencing raw address offsets.
- kllrnohj 8y ago
  > Why wouldn't the WASM JIT retpoline all code (probably only if the underlying processor needs it) rather than relying on the guest programs to do it themselves. Possible, but is that then a runtime option in the WASM header? How does it know if the program needs the cost of retpoline or not? And how can a program ensure that it's getting such mitigations when it needs them? > Once again, wouldn't the JIT be able to enforce this at runtime? The JIT has no insight into the app's malloc/free usage, so no, it can't. There is no system allocator in WASM, just a big chunk of linear memory that the app does whatever it wants with. For an actual case study in why this is risky all you have to do is look at OpenSSL's heartbleed. If it had been using the system's malloc/free (which WASM doesn't have) instead of using its internal free lists then heartbleed largely wouldn't have existed on platforms like OpenBSD.
  - monocasa 8y ago
    > Possible, but is that then a runtime option in the WASM header? How does it know if the program needs the cost of retpoline or not? And how can a program ensure that it's getting such mitigations when it needs them? You're looking at it the wrong way. Untrusted code doesn't have a "I pinky promise that I'm safe" bit they can twiddle in their header. If the code running is untrusted, it doesn't get to make that decision, all code under that context needs to be retpolined. (V8 already does this https://chromium.googlesource.com/v8/v8/+/7d356ac4927e9da3e0c9757e214aa4b20f68acca https://chromium.googlesource.com/v8/v8/+/7d356ac4927e9da3e0... ) > The JIT has no insight into the app's malloc/free usage, so no, it can't. There is no system allocator in WASM, just a big chunk of linear memory that the app does whatever it wants with. It can retarget the code so that the virtual base address of the linear region isn't fixed. That's about all ASLR does anyway. > For an actual case study in why this is risky all you have to do is look at OpenSSL's heartbleed. If it had been using the system's malloc/free (which WASM doesn't have) instead of using its internal free lists then heartbleed largely wouldn't have existed on platforms like OpenBSD. You can implement all of the malloc protection strategies that OpenBSD uses in user space. It's completely legitimate to use your own malloc in those circumstances, libc's malloc isn't magically special, and it makes sense that they'd want to rely on memory allocation with additional guarantees than libc gives you. OpenSSL's sin wasn't re-implementing malloc; it was re-implementing it poorly (and not bounds checking input from attacker controlled packets).
    - brynet 8y ago
      This is ignoring an important benefit of the libc implementations of malloc/free on OpenBSD, free pages are being opportunistically munmap'd at random. This catches actual bugs. Otto Moerbeek has a great recent Twitter thread on the topic: https://twitter.com/ottom6k/status/1065594523559096321 https://twitter.com/ottom6k/status/1065594523559096321 https://twitter.com/ottom6k/status/1063118597160091648 https://twitter.com/ottom6k/status/1063118597160091648 > The JIT has no insight into the app's malloc/free usage, so no, it can't. There is no system allocator in WASM, just a big chunk of linear memory that the app does whatever it wants with. This point by kllrnohj illustrates a pretty significant weakness.
sitkack 8y ago
Please write an essay on how to attack WASM based code and how to structure your codebase to mitigate the outlined flaws. [edit this was not snark, I believe the parent has important insights] I believe it is possible, but the severity seems orders of magnitude less than native code. The host controls the VM interface boundary. Native code can only get this partially via process isolation.

monocasa 8y ago

> which ironically makes real security worse as it means you can't use retpoline Why wouldn't the WASM JIT retpoline all code (probably only if the underlying processor needs it) rather than relying on the guest programs to do it themselves. > HOWEVER it gives up on using guard pages and address randomization (systemic preventions against common bugs like buffer overflows), making WASM in practice less safe than C. Once again, wouldn't the JIT be able to enforce this at runtime? It's not like WASM binaries are referencing raw address offsets.

kllrnohj 8y ago
> Why wouldn't the WASM JIT retpoline all code (probably only if the underlying processor needs it) rather than relying on the guest programs to do it themselves. Possible, but is that then a runtime option in the WASM header? How does it know if the program needs the cost of retpoline or not? And how can a program ensure that it's getting such mitigations when it needs them? > Once again, wouldn't the JIT be able to enforce this at runtime? The JIT has no insight into the app's malloc/free usage, so no, it can't. There is no system allocator in WASM, just a big chunk of linear memory that the app does whatever it wants with. For an actual case study in why this is risky all you have to do is look at OpenSSL's heartbleed. If it had been using the system's malloc/free (which WASM doesn't have) instead of using its internal free lists then heartbleed largely wouldn't have existed on platforms like OpenBSD.
- monocasa 8y ago
  > Possible, but is that then a runtime option in the WASM header? How does it know if the program needs the cost of retpoline or not? And how can a program ensure that it's getting such mitigations when it needs them? You're looking at it the wrong way. Untrusted code doesn't have a "I pinky promise that I'm safe" bit they can twiddle in their header. If the code running is untrusted, it doesn't get to make that decision, all code under that context needs to be retpolined. (V8 already does this https://chromium.googlesource.com/v8/v8/+/7d356ac4927e9da3e0c9757e214aa4b20f68acca https://chromium.googlesource.com/v8/v8/+/7d356ac4927e9da3e0... ) > The JIT has no insight into the app's malloc/free usage, so no, it can't. There is no system allocator in WASM, just a big chunk of linear memory that the app does whatever it wants with. It can retarget the code so that the virtual base address of the linear region isn't fixed. That's about all ASLR does anyway. > For an actual case study in why this is risky all you have to do is look at OpenSSL's heartbleed. If it had been using the system's malloc/free (which WASM doesn't have) instead of using its internal free lists then heartbleed largely wouldn't have existed on platforms like OpenBSD. You can implement all of the malloc protection strategies that OpenBSD uses in user space. It's completely legitimate to use your own malloc in those circumstances, libc's malloc isn't magically special, and it makes sense that they'd want to rely on memory allocation with additional guarantees than libc gives you. OpenSSL's sin wasn't re-implementing malloc; it was re-implementing it poorly (and not bounds checking input from attacker controlled packets).
  - brynet 8y ago
    This is ignoring an important benefit of the libc implementations of malloc/free on OpenBSD, free pages are being opportunistically munmap'd at random. This catches actual bugs. Otto Moerbeek has a great recent Twitter thread on the topic: https://twitter.com/ottom6k/status/1065594523559096321 https://twitter.com/ottom6k/status/1065594523559096321 https://twitter.com/ottom6k/status/1063118597160091648 https://twitter.com/ottom6k/status/1063118597160091648 > The JIT has no insight into the app's malloc/free usage, so no, it can't. There is no system allocator in WASM, just a big chunk of linear memory that the app does whatever it wants with. This point by kllrnohj illustrates a pretty significant weakness.

sitkack 8y ago

Please write an essay on how to attack WASM based code and how to structure your codebase to mitigate the outlined flaws. [edit this was not snark, I believe the parent has important insights] I believe it is possible, but the severity seems orders of magnitude less than native code. The host controls the VM interface boundary. Native code can only get this partially via process isolation.