The ability to take my critical secret information into a huge, buggy, extensible, unaudited, complex and constantly changing browser environment! Who could resist?
This will also inspire innovators world-wide. Look at it this way: we can now find novel ways to steal passwords, secret keys, log sessions, access servers, sneak in trojans.
Count me in.
[0] in a technical sense, the startup focus is quite unique to HN. or maybe I don't subscribe to startup-related subreddits (since startup news is not really the reason I read HN either)
You can find quality conversations in Reddit but, more than likely, not in the default subreddits.
Increasingly I expect a contrarian at the top stating nothing but the obvious fact that there are security implications. Can we stop this now?
People have been complaining that Reddit was taking over years ago and will continue to. Strangely while people posting cat pictures is downvoted for not being productive conversation comments like this get upvoted when it contributes just as much. Heck its even in the guideline:
If your account is less than a year old, please don't submit comments saying that HN is turning into Reddit. (It's a common semi-noob illusion.)
Although I know you have been around for more then a year.
Despite Chrome being speedily updated when known security problems are discovered, the attack surface compared to a dedicated client is huge: the 2-decade-old /usr/bin/ssh + /usr/bin/xterm combo has no concept of a DOM, does not share computing interfaces available to untrusted users (e.g. shared web workers), cannot receive messages from untrusted frames (postMessage()), cannot even be addressed by untrusted content (chrome://path/to/trusted/script), does not almost transparently expose ring0 drivers (OpenGL), does not have thousands of LOC on subsystems with little battle testing (WebRTC) and so on.
Of course these features are thought to be secure, until they are discovered in the midst of a Stuxnet type scenario and suddenly everyone is patching like crazy. Wasn't Java considered invulnerable only 2 weeks ago? Look at what changed - somebody noticed it wasn't long after tens of thousands of infections already occurred, and today it is on every browser's plug-in blacklist. I can't recall the last I read about xterm in the Pwn2Own contest, or any 0-day in the past decade, nor can Google accidentally DoS my xterm because their sync service is down (happened last month).
Following from the truism that the fastest, most bug-free code is code that doesn't exist, the easiest way to reduce exposure to unknown attacks is to minimize the amount of code running. Security design 101. Using something with the complexity of a web browser to render an 80x25 vector used to administer potentially hundreds of thousands of machines is almost the antithesis of good protocol.
An OS that they may or may not update frequently.
An OS that they may or may not be logged into as an admin.
An OS that may have a keylogger running on it.
I think running SSH (or Chrome Remote Desktop) from a Chromebox is a pretty good way to have that minimal OS that is updated frequently, without admin privileges, with a lower risk of a keylogger. That I have to use two-factor to log into, even if my device is stolen.
If you don't want the risk, don't install extensions you don't fully trust. Just like any applications or services on your desktop.
Yes, I agree. The grandparent does point out a valid problem. However I believe the parent was referring to the sarcastic tone and negativity, which I also believe should be out of place here on Hacker News.
xterm is bloated and unmaintainable. Here’s an excerpt from the README:
Abandon All Hope, Ye Who Enter Here
This is undoubtedly the most ugly program in the distribution. It was one of
the first "serious" programs ported, and still has a lot of historical baggage.
Ideally, there would be a general tty widget and then vt102 and tek4014
subwidgets so that they could be used in other programs. We are trying to
clean things up as we go, but there is still a lot of work to do.
I thought it would be obvious to most readers how a tty environment is easier to control than a browser (really, just consider the number and pace of updates to your kernel/windowing system/terminal and your web browser), so I did not bother with lengthy explanations.
The banks operate on the assumption that their user's machines will be compromised and have undertaken plenty of steps to manage their risk e.g. two factor auth, transfer limits etc.
I've written about this before at length, but I'll say it again here: the security practices of most major banks in the US are laughable. This applies to both online and offline banking.
125 000 Euros per transaction (approx. $166 000 at today's rate)
I'd say that I agree with you: they've undertaken plenty of steps to manage their risk like by putting transfer limits.
I'm fairly certain all online brokerages are the same in the limits regard. And yes, tens of thousands of dollars is a huge amount to lose.
I'm just fine with SSH in a browser.
Let's say your online banking browser session was hijacked and the bad guys transfered $100,000 out of your account. First of all the bank is likely to flag that transaction for closer review since it is probably a big departure from your usual behavior. Second, they are going to confirm its accuracy with you, at the very least in a printed or emailed statement to you that it occurred. If they are good, they will call to make sure you meant to do it. Third, they are going to keep records of what happened--the IP address that was connected when the transfer was requested, the time of day, where the money was transferred to, etc.
If it becomes clear that the transfer was a theft, then the bank will cover it as loss and you will get your money back. This is why online banking is not security-critical. Because there are numerous online and offline processes that mitigate the risks associated with online banking.
Now compare to managing your own webserver. The webserver is a dumb machine, not an intelligent counterparty like a bank. If your access to your webserver is hijacked, the webserver will not do a thing to detect, protect, or recover from whatever the bad guys do. Or more specifically, it will do only what you have specifically set it up to do.
By analogy, the lock on the front door of your house is "more important" than the lock on the front door of the police station--because there's no one behind your front door but you, while the police station has dozens of armed and trained officers behind their front door.
It is perfectly possible that Google is doing all sorts of Evil Stuff (TM) in the binaries that they ship out. I don't think it's likely, because a fair few people will be examining the packets it sends -- but it is possible.
With Chrome, that isn't possible. It is based on Chromium, but includes non-open source code, and so you cannot immediately build it.
However, in the end, they're just executables. Looking at assembly isn't quite the same as looking at source code, but we could examine the additional components and try to identify any malicious parts. At least in theory -- the work involved would be quite big.
Pretty sure it's actually very hard, I'd assume they use FDO in their builds.
Actually, this sounds like a fairly interesting project to me: Given a tool chain and a source code base, can we prove this was a possible compilation? In the case of deterministic compilers this is trivial, but as you highlight, not all optimizers are.
You wouldn't be able to compile bit-identical releases due to FDO, but otherwise ...
Re-creating bit-identical copies is hard when you _try_ to make it happen for your project, and I can't see any active efforts for that in most OSS projects.
Timestamps in .o/.lib files, use of system libraries, optimization heuristics, exact versions of the entire toolchain, and many more "fun" issues prevent that from happening, usually.
Yes, and your point is? Security audits do mean much, that's why they are done. Open source means a lot as well, it means that if I don't trust a software, I can check it if I want to, rather than accepting what a company is telling me.
There's a reason why cryptographic stuff is almost exclusively open source, it's because security through obscurity doesn't work.
That said, the amount of exploits for open and closed source software is more of less equivalent, but the time to fix is usually shorter for open source code.
When running OpenSSH inside Chrome on top of Linux you will be affected by any security bug in Linux, OpenSSH or Chrome.
It's not that hard to understand, really.
It's an oversimplification
When you load your SSH-Keys into Chrome and the Chrome sandbox is compromised then there is no further layer between the attacker and your keys.
This is a new attack vector in addition to those that may exist in SSH itself and your operating system.
You're making no sense. The previous attack vectors don't go away when you put your keys into Chrome. Chrome becomes an additional option for the attacker, not an additional "step".
A house with two doors is less secure than the same house with one door.
Yes, you can use ssh-agent with chrome (if they have that implemented, I don't know). Yet you are still in trouble when the chrome sandbox gets compromised, because all your keystrokes are passing through it.
If the sandbox is compromised to have file system access, a process can read your keys from ~/.ssh as well as chrome storage files. Otherwise a webpage has to escape its own sandbox, bypass the native client's sandbox (in a different process) composed of the inner and outer sandbox and then access the native client.
I'm not saying that it's impossible, I'm saying that using a simple analogy as "a house with two doors" might not be the best.
Or there could be just some really dumb bug that somehow enables cross-process access. With javascript. You know, one of these silly brown-paper-bag bugs that are not supposed to happen.
Either way, this is the second door. It may be a shiny steel door, but it's an additional door.
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.
Give me PuTTY or SSH on a terminal any day over this.