4 ms·
Building an SSH client as a Chrome app doesn't introduce attack surface from web content. The SSH client and web content run in different sandboxed processes an
by justinschuh 14y ago
Building an SSH client as a Chrome app doesn't introduce attack surface from web content. The SSH client and web content run in different sandboxed processes and don't share resources. For the web content (or another Chrome app) to break into the SSH client, it would need arbitrary unsandboxed code execution, which means it could manipulate any process running in the user's context. So, the threat model doesn't change from a standalone SSH client.
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.
- patio11 14y agoFor the web content (or another Chrome app) to break into the SSH client, it would need arbitrary unsandboxed code execution 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.
- justinschuh 14y agoI don't mean to be rude, but you seem fundamentally confused. The argument you've strung together here isn't in any way specific to an SSH client built as a Chrome app--and is a just a nebulous claim that applies to any execution contexts sharing the same system.
- comex 14y agoWhat if the attacker compromised the GPU process without compromising the entire sandbox? If hardware compositing is on, they could snoop on the SSH window contents. (Then again, they might be able to do that even with a separate application...)
- justinschuh 14y agoYeah, the GPU process can do this regardless due to the way Windows forces any accellerated GPU app to work. I'm not sure if you dug into this before, but the GPU does run as low-integrity for UIPI purposes on the interactive desktop (lower for other object access). Unfortunately, the desktop window, screen, and display state are still exposed at that level. We're digging into AppContainers to see if tighter restrictions are possible on Win8, but usage is still so low that it's not a priority.
- justinschuh 14y agoSorry I focused solely on Windows, but to my knowledge all platforms we support have similar architectural niggles in terms of the GPU process being able to read anything that's displayed.