Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Security and Correctness in Wasmtime

bytecodealliance.org

Post reply on HN
Print view View original

11–17 of 17 posts

Re: Security and Correctness in Wasmtime

#11

Post by warkdarrior »

RunSet wrote: post #6
mrkurt wrote: post #4

Earlier quoted context omitted.

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.

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.

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?"

Re: Security and Correctness in Wasmtime

#12

Post by RunSet »

RodgerTheGreat wrote: post #7
RunSet wrote: post #6

Earlier quoted context omitted.

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.

I have some bad news for you about PDF: https://opensource.adobe.com/dc-acrobat-sdk-docs/library/jsa... See also: https://rawgit.com/osnr/horrifying-pdf-experiments/master/br...

I intuitively expected some trash like that from Adobe which is why I wrote "every PDF viewer" and not "Acrobat Reader".

Re: Security and Correctness in Wasmtime

#13

Post by capitainenemo »

RunSet wrote: post #12
RodgerTheGreat wrote: post #7

Earlier quoted context omitted.

I have some bad news for you about PDF: https://opensource.adobe.com/dc-acrobat-sdk-docs/library/jsa... See also: https://rawgit.com/osnr/horrifying-pdf-experiments/master/br...

I intuitively expected some trash like that from Adobe which is why I wrote "every PDF viewer" and not "Acrobat Reader".

His "breakout" demo works in Chrome's viewer as well (and obviously FoxIt).

Re: Security and Correctness in Wasmtime

#14

Post by jacobr1 »

RunSet wrote: post #3

> 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 us…

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

Re: Security and Correctness in Wasmtime

#15

Post by saurik »

RodgerTheGreat wrote: post #7
RunSet wrote: post #6

Earlier quoted context omitted.

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.

I have some bad news for you about PDF: https://opensource.adobe.com/dc-acrobat-sdk-docs/library/jsa... See also: https://rawgit.com/osnr/horrifying-pdf-experiments/master/br...

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.

Re: Security and Correctness in Wasmtime

#16

Post by a1369209993 »

warkdarrior wrote: post #11
RunSet wrote: post #6

Earlier quoted context omitted.

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.

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?"

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".

Re: Security and Correctness in Wasmtime

#17

Post by vlmutolo »

infogulch wrote: post #2

This seems like a pretty comprehensive strategy to take wasm security and correctness seriously. It pretty much covers everything I would want to see if I were relying on this system, including auditing, fuzzing, formal correctness, spectre, and even a clear-eyed organizational stance toward reported security vulnerabilities. The post mentions using `cargo vet` to organize audits of third party crates, discussed here…

I previously asked "why cargo vet instead of extending crev" and I think the answer was that architecturally cargo-crev is meant to be a single repository of public audits, where as cargo-vet aims for a decentralized system where anyone can publish an audit anywhere, and each individual project has to opt into which audit databases they trust.

Also cargo-vet has some good ideas about how to suddenly introduce cargo-vet into an existing codebase.

Post reply on HN