HN Theater @HNTheaterMonth

That isn't what I was talking about.

Regarding ActiveX, ever heard of this thing called WebAssembly?

"USENIX Security '20 - Everything Old is New Again: Binary Security of WebAssembly"

https://www.youtube.com/watch?v=glL__xjviro

"USENIX Security '21 - Swivel: Hardening WebAssembly against Spectre"

https://www.youtube.com/watch?v=aLAHmnIkg24

⬐ blep_

WebAssembly is "AOT compiled" in the same sense that code for the JVM/CLR is "AOT compiled".

⬐ pjmlp

Read, my, comment, before, replying.

> That isn't what I was talking about.

A, few, more, comments, upwards.

> Biggest mistake on Java and .NET languages was not having AOT compilation in the box like Delphi and VB 6 (to use common mainstream examples).

⬐ blep_

I am thoroughly confused, because I did read your comments, apparently somehow differently than you read them.

You wrote:

> Had that been the case and probably we would never had the phase of JIT everywhere, followed by doing websites in scripting languages, to come full circle back to AOT compilation and first tier support for systems programing.

And then:

> Regarding ActiveX [the previous AOT compiled web thing], ever heard of this thing called WebAssembly?

You seem to be saying that WebAssembly is an AOT compilation thing that we're coming full circle to, and we're telling you it's not.

⬐ pjmlp

I was replying to the dude that mentioned ActiveX and Web development, even though my ORIGINAL comment made no reference to it, hence why I started my reply with "That isn't what I was talking about.", clear enough?

Usenix Security '20-Everything Old Is New Again: Binary Security of WebAssembly" https://www.youtube.com/watch?v=glL__xjviro

"The Security Risk of Lacking Compiler Protection in WebAssembly"

https://arxiv.org/abs/2111.01421

⬐ slimsag

I talk about how Flash and Java applets can compromise the host OS arbitrarily, and you respond with a paper about how WebAssembly cannot do that but may lead to the program itself running in unexpected, isolated, ways. FTP:

> The standard has been designed with security in mind, as evidenced among others by the strict separation of application memory from the execution environment’s memory. Thanks to this separation, a compromised WebAssembly binary cannot compromise the browser that executes the binary.

⬐ pjmlp

Yes, because first, you can compile heartbleed to WebAssembly.

Secondly, because WebAssembly is yet to become the next target of security researchers, those papers are the first steps.

Third, it is only a bytecode format, it cannot assure anything about the host implementation.

Naturally there are yet flaws to be discovered.

Usenix Security '20-Everything Old Is New Again: Binary Security of WebAssembly" https://www.youtube.com/watch?v=glL__xjviro

"The Security Risk of Lacking Compiler Protection in WebAssembly"

https://arxiv.org/abs/2111.01421

"Usenix Security '20-Everything Old Is New Again: Binary Security of WebAssembly"

https://www.youtube.com/watch?v=glL__xjviro

"The Security Risk of Lacking Compiler Protection in WebAssembly"

https://arxiv.org/abs/2111.01421

You can start here,

"USENIX Security '20 - Everything Old is New Again: Binary Security of WebAssembly"

https://www.youtube.com/watch?v=glL__xjviro

Then there are the issues that since WebAssembly doesn't prevent memory corruption, while RCE attacks or sandboxing breaks are not possible, by producing memory corruption, it is possible to eventually trigger alternative code paths that wouldn't be possible in normal circumstances.

A contrived use case would be to validate a user with higher credentials that they are supposed to have, in a WASM based security module.

Then since the external calls from the module are configured from the runtime, one can do man on the middle attacks on the functions being called from the module, thus access data that it wasn't supposed to be made available in normal cases.

And I bet that when the hacker community starts having fun with WebAssembly, as much as they have had with other bytecode formats, more issues will be found.

⬐ anderspitman

Thanks!

And yet,

"Usenix Security '20-Everything Old Is New Again: Binary Security of WebAssembly"

https://www.youtube.com/watch?v=glL__xjviro

⬐ infogulch

This came across HN before. [1] My conclusion then:

> Notably, they don't appear to even try to break the WA-host memory barrier, which I actually find to be a validation of the core design goal of WebAssembly: isolate the damage a vulnerable program can inflict to the memory space (and thus also output) of that program. Protect the host from the program, but not the program from itself. Also, maybe don't dump WA output you can't validate directly into DOM.

[1]: https://news.ycombinator.com/item?id=24216764

⬐ pjmlp

Regardless, WebAssembly just got one security group doing research against it, I expect plenty more to switch their attention into it, as WebAssemly slowly starts to gather more market share.

> Protect the host from the program, but not the program from itself.

All nice and dandy, except that the goal of WebAssembly is to extend the host, and have the host be dependant on the program behaviour.

A host unaware that the program is compromised can be led to take decisions that it wouldn't otherwise do, like allow a basic user to acquire admin credentials, that were supposedly correctly validated by the program.

I am really eager to see the amount of CVE's on WebAssembly to start poping up, then the whole WebAssembly advocates can tell the world why we had to ditch PNaCL and CrossBridge, 10 years of regress, and get the same outcome in the end.

⬐ afiori

In this context the security guarantees are geared toward the attack threath the web faces: sandboxing untrusted code.

You could say that this is the most web-specific aspect of Web Assebly

⬐ pjmlp

What matters is if WebAssembly actually holds the security guarantees used to sell it in detriment of PNaCL and CrossBridge.

If not, then it was just smoke and mirrors to sell an agenda and delay progress 10 years.

"Unreal Engine 3 Support for Adobe Flash Player - Epic Citadel" -> 2011

https://www.youtube.com/watch?v=xzyCTt5KLKU

⬐ afiori

I know very little about PNaCl, I cannot say whether wasm is better or worse, I am just defending the existence of the specific role for webassembly: lightweight sandboxing with strong sandboxing guarantees. Personally I have high expectations in this strategy.

Regarding the "Everything Old Is New Again: Binary Security of WebAssembly" they find that compiling something like photoshop to a single wasm module forfeits many security features available in x86, but this also point toward a future where application can be compiled in dozens or more small isolated modules. It remains to be seen if this will suceed or fail...

⬐ pjmlp

I lost count how many bytecode formats and sandboxes I have used, or read about.

WebAssembly is what the browsers now offer us, so I have to accept it, that doesn't mean I buy into the security story, specially when basic stuff like bounds checking inside the same linear memory segment is not considered as relevant.

That paper is just the first of many yet to come.

⬐ afiori

That is fair, trust should be earned, not granted; I hope we will see a world where that will happen :)

If they target WebAssembly most likely,

"USENIX Security '20 - Everything Old is New Again: Binary Security of WebAssembly"

https://www.youtube.com/watch?v=glL__xjviro

⬐ nynx

lmao, only if you write something other than rust

⬐ fulafel

There's a lot of unsafe usage in this codebase (https://github.com/ruffle-rs/ruffle/search?q=unsafe returns 5 screenfuls) - though I don't know enough about Rust to tell how risky these are.

⬐ kibwen

In this context any usage of `unsafe` in Rust is probably irrelevant to the safety of the resulting program, because AFAIK the WASM sandbox doesn't trust programs enough to actually allow them to do anything that could potentially violate memory safety.

⬐ fulafel

Yep, in a lot of use cases the wasm version probably is fine with the browser sandbox. But according to the readme this also targets the desktop. I would imagine the desktop mode is native code + wgpu, as there seems to be a wgpu directory under renderer/ .

There are some scenarios when vulnerabilities in a wasm compiled program can be harmful too though. For example the web page embedding the emulated flash applet doesn't necessarily intend to give that app full access to that origin's context. For example it could exfiltrate some api keys or other security tokens of the logged in user of the containing page.

⬐ emi2k01

Around 3.5 of those pages are unsafe uses for implementing the same trait for garbage collection. The implementations seem very simple and the documentation mentions invariants that are easy to hold so it should be easy to recognize an unsound implementation. I think that it should be possible to not use unsafe at all for some of those but I only skimmed over the code so I'm not sure.

Most of the rest of unsafe uses are to skip rust checks that have already been asserted and for FFI which is unavoidable.

There are only a few unsafe uses whose invariants are not well defined. I only gave it a quick look but I doubt they're risky.

Even if an attacker manages to exploit ruffle, I wonder what could they do in a WASM sandbox in an isolated domain.

Politics.

Here is Flash doing the same with CrossBridge toolchain in 2011 with Unreal 3 citadel demo

https://adobe-flash.github.io/crossbridge/

https://www.youtube.com/watch?v=UQiUP2Hd60Y

Then there was PNaCl, but it wasn't good enough hence asmjs, and then WebAssembly, which is supposed to be secure.

Well,

"Usenix Security '20-Everything Old Is New Again: Binary Security of WebAssembly"

https://www.youtube.com/watch?v=glL__xjviro

TedDRA ANDF, IBM i, z/OS, CLR and BREW are all examples of bytecodes that support C and C++.

⬐ kaba0

Yes, I absolutely dislike the direction web browsers went - was just trying to illustrate the point of wasm.

In a more ideal world, I would like to see the JVM underneath modern web browsers