
Exploits in C/C++ to compiled JavaScript / WebAssembly - wglb
https://react-etc.net/entry/web-security-exploits-c-to-javascript-webassembly
======
flohofwoe
The title reads like someone found a new exploit. There's no actual content in
there, instead plain wrong information.

For instance:

> "A practical example of such a bridge from low level to the very top is an
> example where 70 lines of C code exploiting Spectre can be compiled to
> JavaScript / Wasm:"

The code in spectre.c won't compile or work on JS or WASM because it uses
high-precision timing intrinsics not available in the browser sandbox. It was
possible to exploit performance.now(), but all browsers have released updates
which reduce precision of perf.now() dramatically.

May be there are other time sources lurking somewhere in the browser which
could be exploited, but the article is just spreading FUD.

~~~
Scaevolus
I'm looking forward to the first XSS vulnerability that exploits a WASM
module. Control flow integrity _looks_ correct (WASM has a separate return
stack, call and call_indirect validate callee signatures), but use after free
and buffer overflows are still possible.

------
paradroid
There is no proof of concept here. Carry on.

------
EgoIncarnate
I wonder if the author actually tested this.

There is no cache flushing in asm.js or wasm, so a key component of the
example spectre.c, "mm_clflush()" is a no-op.

Even if the example were to compile, I don't see how it would work as is. It
might be possible to attempt an alternative attack where you attempt stuff the
cache and determined what got evicted, but that is a different attack and
certainly not in the vein of "just recompile your c/c++ based exploits for the
web".

------
ohiovr
I'm too lazy to compile the example. Would be nice if they had some actual
proof that didn't require my commission.

------
1ris
the idea4good code was posted here some time ago. After reading the comments I
think it's flawed and doesn't demonstrate anything.

