4 ms·
It's kind of depressing to see that a considerable portion of this depends on design decisions that probably seemed safe at the time but are wildly dangerous in
by kevingadd 9y ago
It's kind of depressing to see that a considerable portion of this depends on design decisions that probably seemed safe at the time but are wildly dangerous in hindsight.
Getting access to the privileged 'crosh' extension in this exploit depends on getting code into its process, which depends on the odd choice to put unrelated extensions into a shared extension process when there's too many processes. Given the insecure nature of the Chrome App Store, this was questionable to begin with - should a potentially backdoored bookmarking extension really share a process with my password safe? - but once privileged Chrome OS code started running in extension processes this immediately became a huge security hole waiting to be exploited.
In this case they also don't even need a compromised extension, because they can (if I understand this right) impersonate an extension's frame and then send messages of their choice to the extension. The access control here is almost entirely done inside the content process, where potentially compromised content is running. It's hard to avoid this since most extension code runs inside content processes by design, but it's a weakness that is rarely (if ever) called out in the chrome extension documentation.
The webassembly exploit part of the chain bums me out (I was always afraid of stuff like this when I was working on the design for it) but it's pretty uninteresting, really. The simple sort of bug you get when you insist on writing stuff in C++.
The parts of the chain after getting access to crosh also seem like tough-to-avoid oversights. This set of attacks definitely make symlinks look like a problem child, given how useful they are for all sorts of naughty behavior the attack gets up to :)
- eugeneionesco 9y ago>The webassembly exploit part of the chain bums me out (I was always afraid of stuff like this when I was working on the design for it) but it's pretty uninteresting, really. The simple sort of bug you get when you insist on writing stuff in C++. I really hope people don't think webassembly is the fault for this, this vulnerability is no different from any other memory corruption vulnerability you would find in the js interpreter or the css parser or whatever.
- standupstandup 9y agoWell, WebAssembly's primary near term contribution will be introducing the world of C++ exploits to web apps, which are already groaning under the load of XSS, XSRF, path traversal, SSRF etc attacks. Adding double frees, use after frees and buffer overflows on top doesn't seem ideal. As for the rest, well, it'd be nice if there was any sort of plan to make Blink safer. I know about oilpan but what Mozilla is doing with Rust is impressive. The JVM guys are working on rewriting the JVM in Java. What's Blink's plan to make its own code safer? Sandboxing alone?
- steveklabnik 9y agoWhat exploits are you specifically worried about with wasm? The ones you call out in this post don’t have the same impact as native, even when it’s C or C++ compiled to wasm.
- standupstandup 9y agohttp://foo.bar.com/url?q=<base64 http://foo.bar.com/url?q=<base64 encoded stuff> wasm program parses q stack smash occurs ROP chain is used to gain code execution user cookie is stolen attacker now controls your account I don't know enough about wasm to know if it has some special mitigations for this but when I looked at it, wasm seemed closer to a CPU emulation than a high level language VM. Flat memory space, no GC, no pointer maps.
- kodablah 9y agoWASM memory is a set of memory specific to a module (and they only allow one memory instance right now). It can be imported/exported to other modules, but there is no sandbox escape (in theory). For the web backend, it's just backed by a UInt8Array IIRC. It's all userland. If anything escapes the WASM interpreter/compiler, it is the fault of the interpreter/compiler (as is the case here) and not the fault of the WASM bytecode itself which has no escape mechanism. Think of a WASM VM just like a JS VM. Even though it may appear low level just because it can JIT better/cleaner, it operates in the same arena as JIT'd JS (at least for the web target).
- pjmlp 9y agoI recently read a paper about security exploits in WebGL, thanks to bugs on shader compilers and drivers. "Automated Testing of Graphics Shader Compilers" http://multicore.doc.ic.ac.uk/publications/oopsla-17.html http://multicore.doc.ic.ac.uk/publications/oopsla-17.html
- kodablah 9y ago> I really hope people don't think webassembly is the fault for this Nah, I think it's pretty clear GP meant "when you insist on writing interpreters/compilers in C++" not that C++ was compiled into wasm.
- kevingadd 9y agoYeah, sorry for being unclear - that is what I meant. I don't see wasm as at fault here, it's just a bummer that this new attack surface was introduced by writing the wasm implementation in C++ instead of memory-safe languages. It's not something so complex that it really needs to be C++. Most (all?) browser wasm backends function by just generating the internal IR used by the existing JS runtime, so it's not especially necessary to write the loader/generator in C++. The generated native module(s) are often cached, also, which diminishes the importance of making the generator fast at the cost of safety. I wrote all the original encoder and decoder prototypes in JS for this reason - you can make it fast enough, and the browser already has a high-performance environment in which you can run that decoder. When the result is already being cached I think writing this in C++ is a dangerous premature optimization. Similarly it's common to write decoders as a bunch of switch statements and bitpacking, which creates a lot of duplication and space for bugs to hide. You can build these things generally out of a smaller set of robust primitives to limit attack surface, but that wasn't done here either, despite my best efforts.