F-Secure Labs

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/

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-WebAssembl… Here's an example vulnerability in WASM parsing leading to RCE: https://labs.f-secure.com/assets/BlogFiles/apple-safari-wasm-section-v…

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.

There was a vulnerability in this technique that was fixed in iOS 11: https://labs.f-secure.com/advisories/apple-ios-host-pairing-bypass/. If someone found another vulnerability and shared it with Cellebrite, then it doesn't work. If they haven't, then it still does.

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-mp… with a video demo here: https://vimeo.com/89924160

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.

See also the F-secure timeline where the salt team's gpg key had been expired for years, salt had a lack of clear communication, and general sloth in response https://labs.f-secure.com/advisories/saltstack-authorization-bypass/

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…