6 ms·

This bug didn't bypass our sandbox so everything is safe and no need to panic.

EE84M3i 5y ago
Wouldn't it be normal to chain another bug for the actual sandbox escape? So this is one part of the chain.
titzer 5y ago
It'd be good to raise the priority of process-wide WX and design out RCEs of this type once and for all. I am disappointed that Wasm is on the exploit chain for a bug like this, as I still feel responsible in some way. I know team priorities change, but this one I pushed hard for commitment on before I left.
- v8dev123 5y ago
  Aaaaaand It's not the first time WASM seen in [0] wild. [0] https://bugs.chromium.org/p/chromium/issues/detail?id=835887 https://bugs.chromium.org/p/chromium/issues/detail?id=835887
  - titzer 5y ago
    Yeah. And it's not even bugs in the Wasm engine that are the problem; the RWX memory for Wasm JIT code makes all other bugs into potential RCE bugs. It must be banished! :)
    - rkangel 5y ago
      Having worked in other spaces ensuring W^X on the basis that there is no good reason for it, the only exception is usually "because I need to code generate". How do you even go about getting rid of WRX in a JIT? Do you generate and then remove W?
      - 0xC0ncord 5y ago
        You pretty much can't, because once memory has been written to at runtime it is assumed to be untrusted. JIT in and of itself is a W^X violation, so the only real solution is to not use it when security over performance is preferred.
        baybal2 5y ago
        Remove support for raw data types from JS. Remove Array buffers, remove blob support, remove anything which can be used to assembly a continuous binary without passing some sanitation.
        wizzwizz4 5y ago
        That isn't sufficient. You know why? exploit("X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*") Okay, so we remove strings. Good thing the in-memory object format isn't known by the atta– wait. Okay, never mind; we can get rid of objects too. And bignums, while we're at it; that leaves us just with bog-standard floating-point integer primitives. Which are stored in a JavaScript call frame. Oops.
        baybal2 5y ago
        1. String are not executable code 2. Can be sanitised to be valid UTF-16 3. Can be intentionally mangled in memory to prevent abuse
        wizzwizz4 5y ago
        1. This one is. 2. Won't help. 3. Simply reverse, or make use of, the mangling.
        baybal2 5y ago
        > 1. This one is. I can check browser memory with a profiler and see if this page is marked as executable. It would not be.

Wouldn't it be normal to chain another bug for the actual sandbox escape? So this is one part of the chain.

It'd be good to raise the priority of process-wide WX and design out RCEs of this type once and for all. I am disappointed that Wasm is on the exploit chain for a bug like this, as I still feel responsible in some way. I know team priorities change, but this one I pushed hard for commitment on before I left.

v8dev123 5y ago
Aaaaaand It's not the first time WASM seen in [0] wild. [0] https://bugs.chromium.org/p/chromium/issues/detail?id=835887 https://bugs.chromium.org/p/chromium/issues/detail?id=835887
- titzer 5y ago
  Yeah. And it's not even bugs in the Wasm engine that are the problem; the RWX memory for Wasm JIT code makes all other bugs into potential RCE bugs. It must be banished! :)
  - rkangel 5y ago
    Having worked in other spaces ensuring W^X on the basis that there is no good reason for it, the only exception is usually "because I need to code generate". How do you even go about getting rid of WRX in a JIT? Do you generate and then remove W?
    - 0xC0ncord 5y ago
      You pretty much can't, because once memory has been written to at runtime it is assumed to be untrusted. JIT in and of itself is a W^X violation, so the only real solution is to not use it when security over performance is preferred.
      - baybal2 5y ago
        Remove support for raw data types from JS. Remove Array buffers, remove blob support, remove anything which can be used to assembly a continuous binary without passing some sanitation.
        wizzwizz4 5y ago
        That isn't sufficient. You know why? exploit("X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*") Okay, so we remove strings. Good thing the in-memory object format isn't known by the atta– wait. Okay, never mind; we can get rid of objects too. And bignums, while we're at it; that leaves us just with bog-standard floating-point integer primitives. Which are stored in a JavaScript call frame. Oops.
        baybal2 5y ago
        1. String are not executable code 2. Can be sanitised to be valid UTF-16 3. Can be intentionally mangled in memory to prevent abuse
        wizzwizz4 5y ago
        1. This one is. 2. Won't help. 3. Simply reverse, or make use of, the mangling.
        baybal2 5y ago
        > 1. This one is. I can check browser memory with a profiler and see if this page is marked as executable. It would not be.