4 ms·

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

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.
      - dbaupp 8y ago
        > In that case, just fall back to bitwise AND index clamping. A small performance penalty, but nothing major. Masking the index will break code that is actually using the larger address space: running true 64-bit WASM code (as in, using >4GB of space) won't work, which is what I was referring to. > page table entries Indeed, hence the reference to virtual memory. In any case, because both x86-64 and ARM64 only have 48 bits of actually addressable space, that 4GB of overhead (plus, up to 4GB of actual addressable memory) only allows for 65536 (or half that) WASM instances. That's definitely a large number, but not one that is out of reach.

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.
    - dbaupp 8y ago
      > In that case, just fall back to bitwise AND index clamping. A small performance penalty, but nothing major. Masking the index will break code that is actually using the larger address space: running true 64-bit WASM code (as in, using >4GB of space) won't work, which is what I was referring to. > page table entries Indeed, hence the reference to virtual memory. In any case, because both x86-64 and ARM64 only have 48 bits of actually addressable space, that 4GB of overhead (plus, up to 4GB of actual addressable memory) only allows for 65536 (or half that) WASM instances. That's definitely a large number, but not one that is out of reach.