5 ms·

How so? WebAssembly can't address memory outside of its sandbox

BeeOnRope 8y ago
The whole point of Spectre is that you can indirectly access memory outside of your "sandbox" even if you don't have permissions to those pages, using various side channels.
- comesee 8y ago
  Aren't those side channels dependent on addressing kernel memory that you don't have permissions for? You can't address kernel memory in WebAssembly, therefore you can't provoke the speculator into caching those pages.
  - hinkley 8y ago
    Oh my sweet summer child. You don’t need to use one exploit if two that interact are common enough. How about a nice pointer arithmetic bug in any reasonably common version of the webasm runtime?
    - TomMarius 8y ago
      Let's assume that the runtime is bugless. What security concerns would be still there, and why?
  - dbaupp 8y ago
    I believe Spectre is driven by processor speculation into a bounds-checked array access, even for when the condition fails (that is, the index is out of bounds). One can get to arbitrary memory in this way using the right index on any array.
    - vardump 8y ago
      Why would you need traditional bounds checking with Wasm? Just use MMU hardware to insert 2GB [0] no man's land below and above Wasm memory and only allow signed 32-bit indexing (-2^31 — 2^31-1). This way the attacker can only read sandbox memory (and the useless 2 GB no man's land, mapped to pages full of zeroes or whatever). When there's no speculation involved or the data is simply out of "speculative range", Spectre is toothless. [0]: 2GB is just a basic example. More may be required if for example something like x86 SIB (Scale Index Base) is used for multiplying the index by 2, 4 or 8.
      - dbaupp 8y ago
        "Just" is never a good word in a technical discussion, especially around security vulnerabilities like Spectre. That's a good idea, but there's also several reasons that may not be appropriate: - WASM explicitly says that it may be extended to 64-bit indexing (more than 4GB of addressable memory is definitely useful for some things) - Spending 4GB of (hopefully, virtual) memory on every WASM instance may be undesirable or impossible (e.g. 32-bit processor) That said, it's very reasonable to impose restrictions on things running in ring-0, and wasmjit could well require a 64-bit machine with 32-bit WASM indices (which I imagine would be okay assumptions for things one would do with it anyway).
        vardump 8y ago
        > - WASM explicitly says that it may be extended to 64-bit indexing (more than 4GB of addressable memory is definitely useful for some things) In that case, just fall back to bitwise AND index clamping. A small performance penalty, but nothing major. > - Spending 4GB of (hopefully, virtual) memory on every WASM instance may be undesirable or impossible (e.g. 32-bit processor) Just page table entries. Wasting physical memory for that would be pointless. If the entries need to be mapped, on x86-64 it'd incur 4 kB, 2 MB or 1 GB total "wasted" memory, depending on which page size granularity you want to use. Of course, you could also simultaneously use this "wasted" memory for any non-sensitive data. Well, mapping 2x 2GB memory using 4kB pages does take up hmm... 8 MB of RAM for the PTEs. So perhaps 2 MB pages would be optimal.
vardump 8y ago
I don't know why you are being modded down. It's indeed possible to avoid ever generating speculative fetches to sensitive data by simply ensuring the indexed access can't ever reach outside the sandbox in the first place, not even in any possible speculated case. Just don't use conditionals and branches to do that, but something else. Like MMU to move data out of range or bitwise AND clamping
pjmlp 8y ago
There is no bounds checking inside WebAssembly itself, as it lacks the concept of fat pointers. So you can still trigger memory corruption if the WebAssembly was generated from languages like C and C++.
- comesee 8y ago
  Again, not in any way that can cause instability to the kernel differently from running the same program in user space.
  - pjmlp 8y ago
    As community should strive for more secure software instead of hand waving security issues.
    - comesee 8y ago
      I never argued that it shouldn't, just that the issues you're raising aren't relevant to the security of running wasm in kernel space.

The whole point of Spectre is that you can indirectly access memory outside of your "sandbox" even if you don't have permissions to those pages, using various side channels.

comesee 8y ago
Aren't those side channels dependent on addressing kernel memory that you don't have permissions for? You can't address kernel memory in WebAssembly, therefore you can't provoke the speculator into caching those pages.
- hinkley 8y ago
  Oh my sweet summer child. You don’t need to use one exploit if two that interact are common enough. How about a nice pointer arithmetic bug in any reasonably common version of the webasm runtime?
  - TomMarius 8y ago
    Let's assume that the runtime is bugless. What security concerns would be still there, and why?
- dbaupp 8y ago
  I believe Spectre is driven by processor speculation into a bounds-checked array access, even for when the condition fails (that is, the index is out of bounds). One can get to arbitrary memory in this way using the right index on any array.
  - vardump 8y ago
    Why would you need traditional bounds checking with Wasm? Just use MMU hardware to insert 2GB [0] no man's land below and above Wasm memory and only allow signed 32-bit indexing (-2^31 — 2^31-1). This way the attacker can only read sandbox memory (and the useless 2 GB no man's land, mapped to pages full of zeroes or whatever). When there's no speculation involved or the data is simply out of "speculative range", Spectre is toothless. [0]: 2GB is just a basic example. More may be required if for example something like x86 SIB (Scale Index Base) is used for multiplying the index by 2, 4 or 8.
    - dbaupp 8y ago
      "Just" is never a good word in a technical discussion, especially around security vulnerabilities like Spectre. That's a good idea, but there's also several reasons that may not be appropriate: - WASM explicitly says that it may be extended to 64-bit indexing (more than 4GB of addressable memory is definitely useful for some things) - Spending 4GB of (hopefully, virtual) memory on every WASM instance may be undesirable or impossible (e.g. 32-bit processor) That said, it's very reasonable to impose restrictions on things running in ring-0, and wasmjit could well require a 64-bit machine with 32-bit WASM indices (which I imagine would be okay assumptions for things one would do with it anyway).
      - vardump 8y ago
        > - WASM explicitly says that it may be extended to 64-bit indexing (more than 4GB of addressable memory is definitely useful for some things) In that case, just fall back to bitwise AND index clamping. A small performance penalty, but nothing major. > - Spending 4GB of (hopefully, virtual) memory on every WASM instance may be undesirable or impossible (e.g. 32-bit processor) Just page table entries. Wasting physical memory for that would be pointless. If the entries need to be mapped, on x86-64 it'd incur 4 kB, 2 MB or 1 GB total "wasted" memory, depending on which page size granularity you want to use. Of course, you could also simultaneously use this "wasted" memory for any non-sensitive data. Well, mapping 2x 2GB memory using 4kB pages does take up hmm... 8 MB of RAM for the PTEs. So perhaps 2 MB pages would be optimal.

vardump 8y ago

I don't know why you are being modded down. It's indeed possible to avoid ever generating speculative fetches to sensitive data by simply ensuring the indexed access can't ever reach outside the sandbox in the first place, not even in any possible speculated case. Just don't use conditionals and branches to do that, but something else. Like MMU to move data out of range or bitwise AND clamping

pjmlp 8y ago

There is no bounds checking inside WebAssembly itself, as it lacks the concept of fat pointers. So you can still trigger memory corruption if the WebAssembly was generated from languages like C and C++.

comesee 8y ago
Again, not in any way that can cause instability to the kernel differently from running the same program in user space.
- pjmlp 8y ago
  As community should strive for more secure software instead of hand waving security issues.
  - comesee 8y ago
    I never argued that it shouldn't, just that the issues you're raising aren't relevant to the security of running wasm in kernel space.