4 ms·
Hi, tech lead of Workers here. This is tricky to answer concisely because we've implemented a huge number and variety of defense-in-depth measures. (Plus, I'm
by kentonv 8y ago
Hi, tech lead of Workers here.
This is tricky to answer concisely because we've implemented a huge number and variety of defense-in-depth measures. (Plus, I'm in transit right now and can't type much -- maybe I'll edit to add more details later.)
First, we believe Chrome has done a pretty good job hardening V8 over the years, and we get a lot of comfort knowing there's a $15,000 bug bounty for V8 breakouts. We update V8 continuously, tracking the version shipping in Chrome.
That said, we obviously don't simply rely on V8 for everything. We've modeled what a V8 breakout is likely to look like, and added a variety of mitigations.
Presumably, a V8 breakout bug is likely to allow an attacker to run arbitrary native code within the Workers runtime process. That's bad, but they will quickly run into some barriers to weaponizing this. For example, we obviously run with ASLR, so an attacker looking for other isolate's data would be flying blind and would likely raise segfaults. Any segfaults in production raise an alert and are investigated. Similarly, we run a tight seccomp fitler that denies all filesystem and network access, and if an attacker ever tries to invoke such syscalls, it will raise an alert and be investigated.
It's worth noting that we do not allow eval() (or any other mechanism of "code generation from strings"), hence all code we execute has to have been uploaded through our code deployment pipeline. This implies we have a copy of all code. When a segfault raises an alert, we immediately look at the code that caused it. Anyone using a zero-day against us is very likely to burn their zero-day long before they manage to pull off a useful attack.
You're probably also wondering about Spectre. Here's a previous comment of mine on that topic: https://news.ycombinator.com/item?id=18280156 https://news.ycombinator.com/item?id=18280156
Again, this is just a couple of the things we're doing... there's really too much to list in a HN comment. I hope to find time to write this up more formally in the future. :)
- jamescostian 8y ago> we do not allow eval() (or any other mechanism of "code generation from strings") This is interesting, because preventing code generation from strings goes beyond `eval()` and `new Function()` - it also includes things like the output www.jsfuck.com can produce (which can indirectly call things like `eval()` and `new Function()` without ever mentioning `eval` or `new Function` in their source). How do you prevent things like that?
- TheDong 8y agoIf you're doing it at the interpreter level, it's pretty easy to prevent even the most obfuscated versions of such functions. You can entirely remove eval such that even if code contained a very obfuscated form of `eval("foo")` it would get "eval is not defined". Since they're not just sanitizing their input, but rather are forbidding things at the runtime level, things like jsfuck.com are totally irrelevant and should have no bearing on their security.
- meowface 8y agoThey're likely not blacklisting strings but actually removing things from the runtime.
- kentonv 8y agoV8's embedding API provides an explicit option to disable them. https://github.com/v8/v8/blob/53d3f5ba2a7ee77244bdee882da9da188daa4c39/include/v8.h#L9097-L9110 https://github.com/v8/v8/blob/53d3f5ba2a7ee77244bdee882da9da... Line 9097, SetAllowCodeGenerationFromStrings()
- azinman2 8y agoHow do you prevent side channel attacks that leak secrets, implementations, or even affect other scripts random number generation? Given the comfort in the bug bounty, and that bugs are inevitable, it seems like cloudflare is willing to risk some exposure to upcoming exploits. How do you feel about this in an era of sophisticated nation states that I’m sure would have a keen interest in being “inside” cloudflare?
- kentonv 8y agoPlease see the comment I linked about Spectre specifically: https://news.ycombinator.com/item?id=18280156 https://news.ycombinator.com/item?id=18280156 I actually think our approach to Spectre -- focusing on preventing the observation of the side channel, rather than blocking speculation -- is likely to be more robust against Spectre variants that haven't been revealed yet. Case in point, we developed some of our core mitigations before we knew about Spectre at all. Spectre affects containers and VMs too.
- azinman2 8y agoSpecter is one class of side channel attack. When you’re in process, I presume there will likely be many more. I meant it as a more general question.
- vasco 8y ago> This implies we have a copy of all code. When a segfault raises an alert, we immediately look at the code that caused it Pretty sure if you run k8s or VMs your company's IP isn't exposed to random engineers at the provider.
- detaro 8y agoI'd be very surprised if you managed to crash a GCP/AWS/Azure hypervisor (or the equivalent in their PaaS offerings) and they went "well, can't look at what's going on, too bad", and their terms of service almost certainly have the leeway to do that as part of a necessary and structured process.
- espadrine 8y agoHi kentonv! Do you trust the model enough to get Workers and Workers KV PCI-DSS Level 1 certified?