11 ms·

This is exactly what I've been waiting for! The ability to take my critical secret information into a huge, buggy, extensible, unaudited, complex and constantl

by jwr 14y ago

This is exactly what I've been waiting for! 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.

salmanapk 14y ago
It might not be very safe at the moment, but this _is_ the future no matter how much you troll.
- deleted 14y ago
  [deleted]
meaty 14y ago
You are the first person to articulate exactly what I think about such things perfectly! Give me PuTTY or SSH on a terminal any day over this.
olalonde 14y ago
"Middlebrow dismissal" comes to mind...
- 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.
- FooBarWidget 14y ago
  What's a middlebrow dismissal? A google search only gave HN results.
  - patio11 14y ago
    It's a word coined by pg that's sort of a term-of-art for the depressing tendency of the top HN comment to be something which pooh-poohs the company/topic/idea in the submission, doesn't add anything to the discussion, but (crucially) is worded convincingly enough to not just end up on the bottom of the thread. 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.
    - jessaustin 14y ago
      This makes sense, but it makes me think that (in the interest of having a good top post) you should have top-leveled your in-depth comment rather than responding to olalonde's as you did. Your comment then could have (and probably would have) been voted up to the top.
    - snowwrestler 14y ago
      Ironically the concept of a "middlebrow dismissal" seems to me to enable what it condemns--e.g. HN'ers can now just post "hey that's a middlebrow dismissal" instead of a detailed statement of why a particular response falls short. Basically I think pg made it worse by giving it a catchy name.
FooBarWidget 14y ago
Yeah, browser-based technology is so unsecure and dubious, it will never catch on for anything security critical such as banking. </sarcasm>
- skeletonjelly 14y ago
  What banking extensions do you use? The one I installed for my bank is a Chrome "app" but really it's just a link.
  - Torgo 14y ago
    Even that has some security utility because it can enable SSL certificate pinning and prevent phishing. I don't know if they're using it that way, but it makes it possible.
- patio11 14y ago
  Critically, there are in fact much worse things you can do to many someones than stealing their online banking session.
- taligent 14y ago
  Online banking isn't security critical. 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.
  - chimeracoder 14y ago
    > 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.
  - martinced 14y ago
    You know what the transfer limit is at my bank? 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.
patrickaljord 14y ago
Chromium is open source, the extension is open source and it runs on nativeclient which itself is open source and was designed and audited to be secure and sandboxed. Making it secure and sandboxed was part of the initial goal of both Chromium and nativeclient, and again, they and the extension are all open source and audited daily by Google engineers and tons of security companies.
- dsr_ 14y ago
  Chromium is open source. Chrome is not. 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.
  - EricBurnett 14y ago
    The same could be said for any binary releases, from open source code or not (e.g. Firefox). If you don't trust Google's binary releases then build your own Chromium from audited sources.
    - mcpherrinm 14y ago
      Yes, trusting binaries is a little scary. But for open source projects like Firefox, you should be able to compile a bit-identical release to what Mozilla provides. 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.
      - tonfa 14y ago
        > But for open source projects like Firefox, you should be able to compile a bit-identical release to what Mozilla provides. Pretty sure it's actually very hard, I'd assume they use FDO in their builds.
alxv 14y ago
Oh right... because putting your critical secret information into a huge, buggy, extensible, unaudited, complex, and constantly changing operating system is so much better!
- moe 14y ago
  When running OpenSSH on top of Linux you will be affected by any security bug in Linux or OpenSSH. 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.
  - BitMastro 14y ago
    Or, from another point of view, an attacker has to bypass Linux and OpenSSH security in one case or bypass Linux, OpenSSH and Chrome security mechanisms in the other case.. It's an oversimplification
    - moe 14y ago
      No. 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.
      - BitMastro 14y ago
        I understand what you mean, but I'm saying that compromising the sandbox can be looked as well as an additional step to achieve. And more so if, for example, address space randomization is offered by the OS. In this case the security model is reinforced, rather than weakened.
        moe 14y ago
        but I'm saying that compromising the sandbox can be looked as well as an additional step to achieve 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.
eliben 14y ago
I'm saddened by the recent shift of HN discussions to Reddit-isms. For Reddit, we have Reddit. Please, stop wasting others' time.
- deleted 14y ago
  [deleted]
- tripzilch 14y ago
  And I am saddened by the not-so-recent yet constant Reddit-bashing over aspects of discussion that appear on HN and not necessarily at all on most programming-related subreddits. Those, in my experience, have a level of discussion quite comparable to HN[0]. [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)
- recycleme 14y ago
  You will find many sarcastic comments in HN. This has nothing to do with Reddit. However, I do appreciate when HNers add in a "/s" or something alike to make it clear that sarcasm was used. You can find quality conversations in Reddit but, more than likely, not in the default subreddits.
- detst 14y ago
  I love HN for discussions like this when a security expert familiar with the Chrome architecture will jump in and break things down (good or bad). Increasingly I expect a contrarian at the top stating nothing but the obvious fact that there are security implications. Can we stop this now?
- cnlwsu 14y ago
  These comments always remind me of this http://xkcd.com/603/ http://xkcd.com/603/ 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.

by jwr 14y ago

salmanapk 14y ago

It might not be very safe at the moment, but this _is_ the future no matter how much you troll.

deleted 14y ago
[deleted]

meaty 14y ago

You are the first person to articulate exactly what I think about such things perfectly! Give me PuTTY or SSH on a terminal any day over this.

olalonde 14y ago

"Middlebrow dismissal" comes to mind...

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.
FooBarWidget 14y ago
What's a middlebrow dismissal? A google search only gave HN results.
- patio11 14y ago
  It's a word coined by pg that's sort of a term-of-art for the depressing tendency of the top HN comment to be something which pooh-poohs the company/topic/idea in the submission, doesn't add anything to the discussion, but (crucially) is worded convincingly enough to not just end up on the bottom of the thread. 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.
  - jessaustin 14y ago
    This makes sense, but it makes me think that (in the interest of having a good top post) you should have top-leveled your in-depth comment rather than responding to olalonde's as you did. Your comment then could have (and probably would have) been voted up to the top.
  - snowwrestler 14y ago
    Ironically the concept of a "middlebrow dismissal" seems to me to enable what it condemns--e.g. HN'ers can now just post "hey that's a middlebrow dismissal" instead of a detailed statement of why a particular response falls short. Basically I think pg made it worse by giving it a catchy name.

FooBarWidget 14y ago

Yeah, browser-based technology is so unsecure and dubious, it will never catch on for anything security critical such as banking. </sarcasm>

skeletonjelly 14y ago
What banking extensions do you use? The one I installed for my bank is a Chrome "app" but really it's just a link.
- Torgo 14y ago
  Even that has some security utility because it can enable SSL certificate pinning and prevent phishing. I don't know if they're using it that way, but it makes it possible.
patio11 14y ago
Critically, there are in fact much worse things you can do to many someones than stealing their online banking session.
taligent 14y ago
Online banking isn't security critical. 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.
- chimeracoder 14y ago
  > 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.
- martinced 14y ago
  You know what the transfer limit is at my bank? 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.

patrickaljord 14y ago

Chromium is open source, the extension is open source and it runs on nativeclient which itself is open source and was designed and audited to be secure and sandboxed. Making it secure and sandboxed was part of the initial goal of both Chromium and nativeclient, and again, they and the extension are all open source and audited daily by Google engineers and tons of security companies.

dsr_ 14y ago
Chromium is open source. Chrome is not. 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.
- EricBurnett 14y ago
  The same could be said for any binary releases, from open source code or not (e.g. Firefox). If you don't trust Google's binary releases then build your own Chromium from audited sources.
  - mcpherrinm 14y ago
    Yes, trusting binaries is a little scary. But for open source projects like Firefox, you should be able to compile a bit-identical release to what Mozilla provides. 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.
    - tonfa 14y ago
      > But for open source projects like Firefox, you should be able to compile a bit-identical release to what Mozilla provides. Pretty sure it's actually very hard, I'd assume they use FDO in their builds.

alxv 14y ago

Oh right... because putting your critical secret information into a huge, buggy, extensible, unaudited, complex, and constantly changing operating system is so much better!

moe 14y ago
When running OpenSSH on top of Linux you will be affected by any security bug in Linux or OpenSSH. 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.
- BitMastro 14y ago
  Or, from another point of view, an attacker has to bypass Linux and OpenSSH security in one case or bypass Linux, OpenSSH and Chrome security mechanisms in the other case.. It's an oversimplification
  - moe 14y ago
    No. 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.
    - BitMastro 14y ago
      I understand what you mean, but I'm saying that compromising the sandbox can be looked as well as an additional step to achieve. And more so if, for example, address space randomization is offered by the OS. In this case the security model is reinforced, rather than weakened.
      - moe 14y ago
        but I'm saying that compromising the sandbox can be looked as well as an additional step to achieve 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.

eliben 14y ago

I'm saddened by the recent shift of HN discussions to Reddit-isms. For Reddit, we have Reddit. Please, stop wasting others' time.

deleted 14y ago
[deleted]
tripzilch 14y ago
And I am saddened by the not-so-recent yet constant Reddit-bashing over aspects of discussion that appear on HN and not necessarily at all on most programming-related subreddits. Those, in my experience, have a level of discussion quite comparable to HN[0]. [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)
recycleme 14y ago
You will find many sarcastic comments in HN. This has nothing to do with Reddit. However, I do appreciate when HNers add in a "/s" or something alike to make it clear that sarcasm was used. You can find quality conversations in Reddit but, more than likely, not in the default subreddits.
detst 14y ago
I love HN for discussions like this when a security expert familiar with the Chrome architecture will jump in and break things down (good or bad). Increasingly I expect a contrarian at the top stating nothing but the obvious fact that there are security implications. Can we stop this now?
cnlwsu 14y ago
These comments always remind me of this http://xkcd.com/603/ http://xkcd.com/603/ 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.