5 ms·

Can I phrase the same objection in a more HN-y manner? SSH terminals are high-sensitivity software. We frequently use them, with very sensitive credentials, t

by patio11 14y ago

Can I phrase the same objection in a more HN-y manner? SSH terminals are high-sensitivity software. We frequently use them, with very sensitive credentials, to log into secured servers. There are two zones of trust involved: we trust that our local machine is not rooted, and we trust that the server is not rooted. The magic of SSL means that no matter how foul everything is between those two zones of trust, we can't get compromised. If we embed the SSH terminal in the browser, we now have four zones of trust: our local machine, the browser, the SSH terminal extension, and the server we connect to. This is a very scary broadening of our attack surface. While the terminal app siting on your machine is decades old and has been tested extensively, the browser extension almost certainly has not. The browser extension, in addition to possibly having vulnerabilities itself, is executing in the context of the browser. The browser is a very scary place to be, because its whole mission in life is connecting to the untrusted, infected cesspool of the Internet and then doing what the Internet tells it to. By grace of God and Google engineers, we generally assume that our browsers aren't going to crack out of the sandbox surrounding the sandbox surrounding the sandbox that all that evil Internet stuff is executing in, but we expect that, in the normal course of operation, those inner sandboxes are going to fall into the hands of the enemy, repeatedly. It therefore seems to be an exceptionally bad idea to take our holiest-of-holy credentials and move them inside the sandbox, closer to the attackers. This is particularly true in terms of a risk/benefit analysis, since the risks are incredible and the only benefit is "Saves you from having to do a single key chord to pop open an additional terminal on your machine." This is moot if you have total confidence in the Chrome and Native Client teams to never have a mistake which lets someone, e.g., read arbitrary process memory. That's happened before -- Mark Dowd et al found it. That would be pretty sucky if it happened on a browser you logged into your bank, because the attacker can probably grab your cookie and banking session. It would be much worse, though, if it happened on a machine used by a bank sysadmin who unwisely decided to use a terminal within his browser, because why steal one session when you can just steal the bank? (n.b. Note how this is possible without causing Chrome to execute arbitrary code or defeating the OS's protections against Chrome doing stuff outside the Chrome-box.)

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.

by patio11 14y ago

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.