"Middlebrow dismissal" comes to mind...
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.)
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."
Java and Flash are two of the most widely compromised pieces of software in history.
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.
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.
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.
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.
Client-side exploits in SSH clients have happened before[1]. The scope of such exploits is arguably reduced when running a sand-boxed application in a browser compared to a regular application on the local machine.
That being said, I agree with your general point that using a browser as an SSH terminal dramatically increases the attack surface, compared to a small dedicated client.
[1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0467
Multiple integer overflows in the (1) sftp_pkt_getstring and (2) fxp_readdir_recv functions in the PSFTP and PSCP clients for PuTTY 0.56, and possibly earlier versions, allow remote malicious web sites to execute arbitrary code via SFTP responses that corrupt the heap after insufficient memory has been allocated.
[Edit: On re-reading, I think I misunderstood this, and the comment beneath this one is substantially correct regarding them bundling OpenSSH. I still think this is substantially more attack surface than however you're consuming OpenSSH code currently.]
Secure Shell is a Chrome Application that combines the "ssh" command (see http://openssh.org/ for details) ported to NativeClient with the "hterm" terminal emulator to provide a secure shell client for the Chrome browser.
http://git.chromium.org/gitweb/?p=chromiumos/platform/assets...
I'm not familiar enough with the multiple sandboxing levels of Chrome to judge the risks of one malicious website accessing the memory of the Secure Shell extension. I guess you have a point, although I would expect the "each tab in a separate process" model to mitigate this concern?
This is running OpenSSH code.
Why? The whole model of Chrome is that there's a multi-process conglomerate with clearly defined interfaces between them and OS enforced boundaries otherwise.
Why would it be easier for a malicious JS payload running on Process A to attack the Chrome SSH extension running on Process B than to attack the terminal or openssh processes?
The bugs Mark found in NaCl several years ago don't alter the threat model for a standalone SSH client either. And for context, Mark's work was done while NaCl was in alpha development, years before it shipped in Chrome; were performed as part of a Google sponsored contest and later a Google paid audit; and applied to the NaCl validator sandbox, not the outer process isolation sandbox. So, even the more nebulous threat you're implying is grossly misstated.
Respectfully, I think you might be limiting the attack space here in a fashion that attackers are not restricted to doing. For example, there appear to me to be opportunities for side channel attacks which do not require the bad guys to totally break your sandbox model for them to be able to guess at what another Chrome process is doing. Given that they'll have a local vantage point to do the timing measurements, and consequently very high precision, it's at least possible that they can guess things about the operation of the SSH process. If the guess the right things, they don't need to cause the SSH process to execute any code at all. (If memory serves me, that's previously been used to time OpenSSL's encryption/decryption itself, but there's probably other vectors if that isn't an option these days, like timing I/O operations with sufficient precision to guess what they were.)
There's an interesting question on whether moving the SSH into a Chrome process makes it more vulnerable vis-a-vis other Chrome processes to timing attacks than it would be just by being on the same box with a Chrome process. I would not trust myself to say "That is definitely more of a risk" with the level of research I've done, but I think it is highly unlikely that it gets less risky.
Thanks for the reminder that new software is less secure than old, and that new technologies often widen attack surfaces. There is little doubt in my mind that this is just the beginning of Chrome native apps, and they have to start somewhere.
e.g. "Lol that suckz because Google can steal ur passwerdz!" would not end up at the top of the thread. We wouldn't be terribly worried if someone actually said "Wait, I just audited NativeClient and it turns out you can achieve arbitrary code execution. Maybe you should avoid this software." The danger zone is comments which sound like the second but, on reflection, only tell you about as much as the first.
Basically I think pg made it worse by giving it a catchy name.