Hacker News new | past | comments | ask | show | jobs | submit login

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.




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


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.


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.


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.


There is also no reason that private keys have to be loaded in the same process (or even the sandbox) when an ssh agent is used.


I'm a bit baffled to what degree some people here try to deny the obvious.

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.


From what I know they don't impement ssh-agent. Do you consider ssh-agent as another attack vector or additional security?

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.


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.

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.


The other process might as well be ssh itself at this point. Anyway, we are just speculating, also the wall is another door if you smash through it. Just don't use it then.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: