4 ms·

> WebAssembly programs are sandboxed and isolated from one another and from the host, so they can’t read or write external regions of memory, transfer control t

by RunSet 4y ago

> WebAssembly programs are sandboxed and isolated from one another and from the host, so they can’t read or write external regions of memory, transfer control to arbitrary code in the process, or freely access the network and filesystem. This makes it safe to run untrusted WebAssembly programs: they cannot escape the sandbox to steal private data from elsewhere on your laptop or run a botnet on your servers. As if users will not concede every requested permission to the first Monero miner that asks.

jacobr1 4y ago
But the malicious miner won't be stealing the banking credentials you used in a different tab
mrkurt 4y ago
They might, but that's the wrong way to think about security. It is true that people can be tricked into bypassing any security layer. It is also true that strong security boundaries are useful tools.
- RunSet 4y ago
  A more meaningful security boundary might be making HTML viewers' ability to run arbitrary code an opt-in feature, rather than opt-out. Imagine if every PDF viewer included a virtual machine that ran in the background while viewing the document.
  - warkdarrior 4y ago
    Opt-in code execution is not a meaningful security mechanism because users do not have the expertise or information to answer a prompt like "Do you want to allow this web page to run code?"
    - a1369209993 4y ago
      Prompts are not opt-in. Opt-in is moving the mouse to (say) the lower-right corner, clicking on the NoScript icon, and selecting "Temporarily allow example.com". That's not a panacea, but it at least raises the bar from "get people to even briefly look at your attack site", to "come up with a at-least-vaguely-plausible excuse why your site needs to be handed a remote code execution vulnerability in order to function".
  - RodgerTheGreat 4y ago
    I have some bad news for you about PDF: https://opensource.adobe.com/dc-acrobat-sdk-docs/library/jsapiref/index.html https://opensource.adobe.com/dc-acrobat-sdk-docs/library/jsa... See also: https://rawgit.com/osnr/horrifying-pdf-experiments/master/breakout.pdf https://rawgit.com/osnr/horrifying-pdf-experiments/master/br...
    - RunSet 4y ago
      I intuitively expected some trash like that from Adobe which is why I wrote "every PDF viewer" and not "Acrobat Reader".
      - capitainenemo 4y ago
        His "breakout" demo works in Chrome's viewer as well (and obviously FoxIt).
    - saurik 4y ago
      Even better, every font renderer does! A couple of the PDF-based jailbreaks for iOS were actually bugs in the virtual machine used by font renderer to allow fonts to do programmatic hinting, and the PDF only really existed as a container to deploy the font and force it to deterministically render exactly what was required.
ridruejo 4y ago
The “user” may be a multi tenant system for say, FaaS
pjmlp 4y ago
No need to, the data inside of the sandbox can still be corrupted (C compiled into WASM code), so even if it doesn't escape to the host, there are tons of possible ways to exploit the code and via data corruption force it to execute another code path thanks to incorrect state on the data structures.

by RunSet 4y ago

jacobr1 4y ago

But the malicious miner won't be stealing the banking credentials you used in a different tab

mrkurt 4y ago

They might, but that's the wrong way to think about security. It is true that people can be tricked into bypassing any security layer. It is also true that strong security boundaries are useful tools.

RunSet 4y ago
A more meaningful security boundary might be making HTML viewers' ability to run arbitrary code an opt-in feature, rather than opt-out. Imagine if every PDF viewer included a virtual machine that ran in the background while viewing the document.
- warkdarrior 4y ago
  Opt-in code execution is not a meaningful security mechanism because users do not have the expertise or information to answer a prompt like "Do you want to allow this web page to run code?"
  - a1369209993 4y ago
    Prompts are not opt-in. Opt-in is moving the mouse to (say) the lower-right corner, clicking on the NoScript icon, and selecting "Temporarily allow example.com". That's not a panacea, but it at least raises the bar from "get people to even briefly look at your attack site", to "come up with a at-least-vaguely-plausible excuse why your site needs to be handed a remote code execution vulnerability in order to function".
- RodgerTheGreat 4y ago
  I have some bad news for you about PDF: https://opensource.adobe.com/dc-acrobat-sdk-docs/library/jsapiref/index.html https://opensource.adobe.com/dc-acrobat-sdk-docs/library/jsa... See also: https://rawgit.com/osnr/horrifying-pdf-experiments/master/breakout.pdf https://rawgit.com/osnr/horrifying-pdf-experiments/master/br...
  - RunSet 4y ago
    I intuitively expected some trash like that from Adobe which is why I wrote "every PDF viewer" and not "Acrobat Reader".
    - capitainenemo 4y ago
      His "breakout" demo works in Chrome's viewer as well (and obviously FoxIt).
  - saurik 4y ago
    Even better, every font renderer does! A couple of the PDF-based jailbreaks for iOS were actually bugs in the virtual machine used by font renderer to allow fonts to do programmatic hinting, and the PDF only really existed as a container to deploy the font and force it to deterministically render exactly what was required.

ridruejo 4y ago

The “user” may be a multi tenant system for say, FaaS

pjmlp 4y ago

No need to, the data inside of the sandbox can still be corrupted (C compiled into WASM code), so even if it doesn't escape to the host, there are tons of possible ways to exploit the code and via data corruption force it to execute another code path thanks to incorrect state on the data structures.