3 ms·

Complexity is a risk, but we also care deeply about performance and startup time in much the same ways Chrome does. So we need that JIT. I'm comforted by the f

Complexity is a risk, but we also care deeply about performance and startup time in much the same ways Chrome does. So we need that JIT. I'm comforted by the fact that if there's a breakout in V8, Chrome is a much juicier target than we are -- and has an incredibly strong security team that will jump on the issue. I think we would be overall less secure using a lesser-known JS implementation.

mwcampbell 8y ago
Actually, I think Cloudflare is a juicier target, due to a combination of two things: 1. No process isolation 2. Data from lots of users on any given node Am I missing something?
- kentonv 8y ago
  While I don't mean to deny the risk, which we take very seriously, I do think there's a number of reasons Chrome remains a much more interesting target: * While process isolation makes Chrome somewhat less interesting than it used to be, keep in mind that process isolation is being rolled out as a defense to arbitrary-read attacks (like spectre), not arbitrary-code-execution attacks. Executed code can potentially talk to the rest of Chrome and perform actions that a web site is not intended to be allowed to. (At least in the past, this included the ability to read all the user's cookies, though it's possible they've improved on that, I don't know.) * Cloudflare has potentially multiple tenants in a node, but the attacker has no control over who they are. There's no particularly good way to target a specific end user nor a specific web site. * V8 vulnerabilities are likely to be memory safety issues, which are difficult to leverage into an attack without an understanding of the process's memory space, which is hard to get without having access to the source code or a compiled binary. The attacker would be flying blind and would almost certainly just segfault or be caught by our layer 2 sandbox (which blocks almost all syscalls), which incidentally would immediately alert us to their activity. (I don't particularly like this as a defense, since I like open source -- but frankly, it is a pretty big barrier.) * The attacker would be burning their zero-day by uploading it to Cloudflare. We block eval() and the like, such that the only way to run code on our edge is by uploading it through our deployment APIs, which keep a copy. * Last I checked, Chrome still does not use site isolation on mobile, because the overhead is too high.

mwcampbell 8y ago

Actually, I think Cloudflare is a juicier target, due to a combination of two things: 1. No process isolation 2. Data from lots of users on any given node Am I missing something?

kentonv 8y ago
While I don't mean to deny the risk, which we take very seriously, I do think there's a number of reasons Chrome remains a much more interesting target: * While process isolation makes Chrome somewhat less interesting than it used to be, keep in mind that process isolation is being rolled out as a defense to arbitrary-read attacks (like spectre), not arbitrary-code-execution attacks. Executed code can potentially talk to the rest of Chrome and perform actions that a web site is not intended to be allowed to. (At least in the past, this included the ability to read all the user's cookies, though it's possible they've improved on that, I don't know.) * Cloudflare has potentially multiple tenants in a node, but the attacker has no control over who they are. There's no particularly good way to target a specific end user nor a specific web site. * V8 vulnerabilities are likely to be memory safety issues, which are difficult to leverage into an attack without an understanding of the process's memory space, which is hard to get without having access to the source code or a compiled binary. The attacker would be flying blind and would almost certainly just segfault or be caught by our layer 2 sandbox (which blocks almost all syscalls), which incidentally would immediately alert us to their activity. (I don't particularly like this as a defense, since I like open source -- but frankly, it is a pretty big barrier.) * The attacker would be burning their zero-day by uploading it to Cloudflare. We block eval() and the like, such that the only way to run code on our edge is by uploading it through our deployment APIs, which keep a copy. * Last I checked, Chrome still does not use site isolation on mobile, because the overhead is too high.