5 ms·

Interestingly, Google appears to be largely thinking of the opposite threat model: http://git.chromium.org/gitweb/?p=chromiumos/platform/assets.git;a=blob;f=ch

by patio11 14y ago

Interestingly, Google appears to be largely thinking of the opposite threat model: http://git.chromium.org/gitweb/?p=chromiumos/platform/assets.git;a=blob;f=chromeapps/hterm/doc/faq.txt http://git.chromium.org/gitweb/?p=chromiumos/platform/assets... Additionally, the Secure Shell application follows a strict Content SecurityPolicy that does not allow access to the JavaScript 'eval' function. This helps lower the risk that a terminal exploit could run arbitrary JavaScript. Translation: Don't worry, if the bad guys already own your server/local machine, it's less likely they'll be able to go from owning your server/local machine to owning your browser, because we make them have to jump through a few hoops to execute arbitrary Javascript. I'm having one of those rare, weird moments where I disagree with someone I enormously respect in a field, on that field, and think -- even after reflecting -- that even with the "They're so smart about this they're probably seeing something you aren't" modifier the words that are coming out of their mouth are, in fact, not right. Edit to add: I previously used the language "batshit crazy", but on reflection you could envision an attack like "Attacker gets arbitrary content written into a web server log; if we cat this in the JS context, we turn totally harmless text that wasn't executing on the server or the local terminal into executable Javascript." But I still really think that is less likely and less severe than bootstrapping a browser, NativeClient, or extension bug into "Root all the boxes."

taligent 14y ago
We have all seen these browser sandboxes before. And guess what: Java and Flash are two of the most widely compromised pieces of software in history.
- BitMastro 14y ago
  And guess what, they're also two of the most widely installed software. The truth is that sandboxes are effective in mitigating the attacks, because they add another level of security. Even safari added a sandbox a couple years ago.
- justinschuh 14y ago
  It hurts my head to see people refer to a "sandbox" as if the term means anything in isolation. Sandboxing is a strategy that covers a broad spectrum of implementation quality. Take Java's "sandbox," which is just its VM layer employing a complicated stack inspection based permission model. In practice it's very porous, and has a very poor security history at various levels. You also mentioned Flash, which has a VM "sandbox" for Actionscript, with a simpler, mostly origin-based security model. Depending on the platform there's also an outer Flash sandbox using OS-based security primitives to various degrees. Since Adobe built their own NPAPI sandbox on Windows (mostly for Firefox), it's a good one to point to. It prevents write-level access to most objects, and relies on a broker process to manage those actions. Most objects are readable from inside the sandbox, and various low-privilege objects can be directly controlled as well. Historically, Flash has a better security track record than Java, but has still had its share of issues. Then there's the Chrome sandbox. Once again, there's a VM level "sandbox" for JavaScript and one for NaCl nexes, both using a strict origin-based security model. Then there's an outer sandbox using the OS-based primitives that deny access to all objects, requiring all resource access to be routed through a broker process. Chrome is generally considered to be very good on the security front, and has yet to be hit with an exploit in the wild. I could actually into very deep detail on how these differ, and the effectiveness of each sandbox implementation, but I think the broad descriptions convey my point.
JoachimSchipper 14y ago
It is possible to use this sensibly - e.g. I don't really see the problem with using this to play a MUD/roguelike/etc. In that context, their security worries make complete sense. On the other hand, for certain environments, browser access is game over anyway. I'd expect that snarfing your customers' credit card info out of your admin consoles would get an attacker 99% of the value (s)he'd get from completely rooting you - just how careful are you about separating the internet and your admin consoles? Just how careful is the average HN user? (Note that your admin consoles would need a custom attack, though, while "open a reverse shell when logging in" would be considerably more general.) But yes, for many, many people, this is really scary.
Spooky23 14y ago
I tend to agree with you, as most folks would. But perhaps this approach is being driven by the "Chrome as Operating System" approach and the Chromebook. Google is a big enough company that the thought process is being driven the by internal needs and wants, not necessarily by what the rest of the universe is doing.

by patio11 14y ago

taligent 14y ago

We have all seen these browser sandboxes before. And guess what: Java and Flash are two of the most widely compromised pieces of software in history.

BitMastro 14y ago
And guess what, they're also two of the most widely installed software. The truth is that sandboxes are effective in mitigating the attacks, because they add another level of security. Even safari added a sandbox a couple years ago.
justinschuh 14y ago
It hurts my head to see people refer to a "sandbox" as if the term means anything in isolation. Sandboxing is a strategy that covers a broad spectrum of implementation quality. Take Java's "sandbox," which is just its VM layer employing a complicated stack inspection based permission model. In practice it's very porous, and has a very poor security history at various levels. You also mentioned Flash, which has a VM "sandbox" for Actionscript, with a simpler, mostly origin-based security model. Depending on the platform there's also an outer Flash sandbox using OS-based security primitives to various degrees. Since Adobe built their own NPAPI sandbox on Windows (mostly for Firefox), it's a good one to point to. It prevents write-level access to most objects, and relies on a broker process to manage those actions. Most objects are readable from inside the sandbox, and various low-privilege objects can be directly controlled as well. Historically, Flash has a better security track record than Java, but has still had its share of issues. Then there's the Chrome sandbox. Once again, there's a VM level "sandbox" for JavaScript and one for NaCl nexes, both using a strict origin-based security model. Then there's an outer sandbox using the OS-based primitives that deny access to all objects, requiring all resource access to be routed through a broker process. Chrome is generally considered to be very good on the security front, and has yet to be hit with an exploit in the wild. I could actually into very deep detail on how these differ, and the effectiveness of each sandbox implementation, but I think the broad descriptions convey my point.

JoachimSchipper 14y ago

It is possible to use this sensibly - e.g. I don't really see the problem with using this to play a MUD/roguelike/etc. In that context, their security worries make complete sense. On the other hand, for certain environments, browser access is game over anyway. I'd expect that snarfing your customers' credit card info out of your admin consoles would get an attacker 99% of the value (s)he'd get from completely rooting you - just how careful are you about separating the internet and your admin consoles? Just how careful is the average HN user? (Note that your admin consoles would need a custom attack, though, while "open a reverse shell when logging in" would be considerably more general.) But yes, for many, many people, this is really scary.

Spooky23 14y ago

I tend to agree with you, as most folks would. But perhaps this approach is being driven by the "Chrome as Operating System" approach and the Chromebook. Google is a big enough company that the thought process is being driven the by internal needs and wants, not necessarily by what the rest of the universe is doing.