F-Secure Labs is the security firm's research blog, with vulnerability write-ups on counterfeit Cisco gear, BitLocker, smart TVs, and Safari.
HN commenters cite its work such as the TamaGo bare-metal Go project and the iOS host pairing bypass advisory, in discussions on security research.
I am not sure I understand the sentence "limiting the WA spec to only try to sandbox the WA binary from outside memory". I would not say that we (as in: the authors of the paper) are trying to limit the spec, or that we tried to only look into those parts of the spec that are not concerned with security. (I hope I do not misunderstand your point.) The spec/language/memory organization of WebAssembly really does not do much to provide security inside a WebAssembly program's own memory.
I do agree with you, however, that our findings do not invalidate the overall design of WebAssembly. I really like the simplicity and generality of WebAssembly, and the technical (and social) achievement of having a "universal bytecode" supported in four different JavaScript engines (and some standalone VMs), on top of several different hardware architectures (x86, x86-64, ARM, etc.), with good performance, etc. I also think "host security" (which we are not really looking into) is solid, with two qualifications:
* In browsers, WebAssembly is sandboxed like JavaScript is, which is well tested.
* In other host environments (in particular, standalone VMs) the story might be different. It is hard to make any general statements about host security without talking about the concrete host at hand.
> they don't appear to even try to break the WA-host memory barrier
That's correct. However, just because we did not try, I would not say that breaking out of WebAssembly memory is impossible. But…
This reminds me of when I was an intern at an InfoSec company 6 years ago. At the time, they were doing some research into mPOS devices (though I wasn't involved).
They found and exploited a stack-based buffer overflow in the EMV parsing of a particular device, which allowed them to deliver a payload from the smart-card itself. To demo this attack, they wrote a flappy bird clone which was played using the number pad of the mPOS device. It weighed in at ~4k though, so positively heavyweight compared to this!
There's more info here: https://labs.f-secure.com/assets/BlogFiles/MWRI-Labs-BHUS14-Mission-mpossible-2014-08-04-2.pdf, with a video demo here: https://vimeo.com/89924160
Perhaps, you can start by learning what WASM is:
https://developer.mozilla.org/en-US/docs/WebAssembly
As for vulnerabilities, here are nccgroup's slides about WASM explots:
https://i.blackhat.com/us-18/Thu-August-9/us-18-Lukasiewicz-WebAssembly-A-New-World-of-Native_Exploits-On-The-Web.pdf
Here's an example vulnerability in WASM parsing leading to RCE:
https://labs.f-secure.com/assets/BlogFiles/apple-safari-wasm-section-vuln-write-up-2018-04-16.pdf
I really like Twinkly lights. You can 3D map lights on the christmas tree with your phone and then play with individually controllable RGBW light points. They are relatively cheap, even non-DIY people can buy and use them. It would be great if they provided some official API, but if you want to hack them, there are ways to do it: https://labs.f-secure.com/blog/twinkly-twinkly-little-star/
This blog article from February of this year gives some context: https://labs.f-secure.com/blog/tamago/
> TamaGo reduces the attack surface of embedded systems firmware by removing any run time dependency on C code and inherently complex Operating Systems.
> It does so with minimal changes to the Go run time and a set of packages to provide drivers for supported boards.
Actually some people actually chose Go instead, to prove a point,
https://www.f-secure.com/en/consulting/foundry/usb-armory
https://labs.f-secure.com/blog/tamago/
> Our work focuses in supporting free standing Go applications that can be coded as usual, while running on bare metal hardware and without an underlying OS.