When installing, especially on an untrusted host, follow the manual installation instructions. The menu item will just output a curl|bash command (currently; this will likely change in the future).
If the host is really untrusted you're screwed, of course. Bad guys could modify your ~/.iterm2_shell_integration.bash and you'd never know. But this script is not special in any way (except that it's kinda complex and is run automatically). Maybe hash it from time to time if you're really paranoid.
The scripts assume that various things in your path are safe to run. printf, hostname, sed, echo, etc. If those are compromised you're in a bad way, and I don't think shell integration exposes anything that ordinary use wouldn't.
If you've been compromised badly enough that an attacker can decrypt your ssh session, your current directory will be revealed at each prompt. But it probably is since most people have that in their $PS1 anyway. Also the host's idea of its fully-qualified domain name.
Probably the most risky aspect of shell integration is the secure copy feature. It's possible that there's a bug in my use of libssh2 or that there are unpatched vulnerabilities in an out-of-date build of iTerm2 (or an up-to-date version of iTerm2 with an out-of-date libssh2). I try to stay on top of changes to libssh2 but I am human and Sparkle (the auto-updater) is not flawless either.
That's all that comes to mind. I'm sure other folks on here can think of more interesting attacks or vulnerabilities.
Is there a risk of the untrusted host injecting things into the shell output without permission? It looks like there's no authentication, so if I SSH somewhere untrusted that can output raw characters to my shell (which, I believe, includes git pushing over SSH, etc.), it can output the right escape sequence and insert false things into my shell history. With further cleverness, it could almost certainly inject things that look like commands I would have run but actually run evil things.
I don't have a great solution to suggest for this. One option is to add some sort of per-user static password to the escape sequence, and insert it in the file that's copied to each (trusted) host, but that just seems questionable. A better one might be to make the communication use a socket instead of an escape sequence, and forward the socket (recent OpenSSH can forward UNIX domain sockets) to trusted hosts, but that's its own mess.
This is such a useful feature, though, especially with remote hosts. It'd be a pity if it can't be done securely. :/
(While we're on the subject of security, there's an obscure attack involving interrupting the download of a `curl | sh` script -- which a MITM can do, even over SSH -- and relying on the shell to execute a partial command line. I learned about this from the Sandstorm folks, who have a workaround in https://install.sandstorm.io/ involving the sh equivalent of an IIFE.)
Yeah, it's possible they could do that if you're on a shared machine with a world-writable tty, or if a program blindly outputs info from an evil server. There's a good chance you'd notice something hinky going on, and of course there's no guarantee you'd run a command in history. Also, when you double-click on a command in history, you still need to press enter to execute it, so you'd have a chance to review the evil command. And if you're using a terminal that doesn't swallow unrecognized sequences (like Gnome terminal) you'd see the guts of the escape sequence.
Your password idea would work. It would be nearly impossible to establish a shared secret, unfortunately. It's really hard to do any kind of authentication over a one-way channel, which you almost always have to assume is what you've got in the world of terminal emulation. Key management retains its title as the worst part of crypto. The socket thing doesn't work (at least as the default mode) because nobody knows how to forward sockets and 99% of users would choose to forego the feature over learning a new ssh flag and making it work everywhere. There are gnarly race conditions there, too. How do you correlate prompts with messages on the socket?
I'm open to suggestions, but I don't see a way to make it both convenient enough to be generally useful and bulletproof.
I do plan to nuke the curl|bash thing. It was a shortcut to ship faster and to make it easy to update scripts in the field quickly when bugs were found. I did imagine everyone on hacker news scowling at me when I wrote that code, FWIW.
> The socket thing doesn't work (at least as the default mode) because nobody knows how to forward sockets
I suspect that you can do this with SSH configuration (LocalForward ~/.something:~/.something), but I haven't tested it. It mostly depends on whether you're willing to configure this, but perhaps the installer can put that at the top of ~/.ssh/config, so it's global, with a comment saying "If you don't want this globally, delete it or put it after a `Host example.com` line". Even if you trusted all SSH hosts, this would protect you from the git-clone attack.
You could probably also abuse X11 forwarding for this, which has the advantage that trusted X11 forwarding is basically the right security boundary and is just `ssh -Y`, and the disadvantage that now you're relying on X11 (or worse, a custom X11-speaking proxy so you can avoid requiring the server or client) on both sides.
> There are gnarly race conditions there, too. How do you correlate prompts with messages on the socket?
Send a token or hash in-band, and send the actual command out-of-band. If you receive an unknown token, ignore it.
> I do plan to nuke the curl|bash thing. It was a shortcut to ship faster and to make it easy to update scripts in the field quickly when bugs were found. I did imagine everyone on hacker news scowling at me when I wrote that code, FWIW.
:-)
curl https:// | sh is IMO a perfectly reasonable way to install software (at least in a world where ./configure && make install is reasonable; I don't know any humans who can audit the output of GNU autoconf). It just has this one weird problem. I sort of dislike the stigmatization of it precisely because it's hard to talk about how to do it well.
When installing, especially on an untrusted host, follow the manual installation instructions. The menu item will just output a curl|bash command (currently; this will likely change in the future).
If the host is really untrusted you're screwed, of course. Bad guys could modify your ~/.iterm2_shell_integration.bash and you'd never know. But this script is not special in any way (except that it's kinda complex and is run automatically). Maybe hash it from time to time if you're really paranoid.
The scripts assume that various things in your path are safe to run. printf, hostname, sed, echo, etc. If those are compromised you're in a bad way, and I don't think shell integration exposes anything that ordinary use wouldn't.
If you've been compromised badly enough that an attacker can decrypt your ssh session, your current directory will be revealed at each prompt. But it probably is since most people have that in their $PS1 anyway. Also the host's idea of its fully-qualified domain name.
Probably the most risky aspect of shell integration is the secure copy feature. It's possible that there's a bug in my use of libssh2 or that there are unpatched vulnerabilities in an out-of-date build of iTerm2 (or an up-to-date version of iTerm2 with an out-of-date libssh2). I try to stay on top of changes to libssh2 but I am human and Sparkle (the auto-updater) is not flawless either.
That's all that comes to mind. I'm sure other folks on here can think of more interesting attacks or vulnerabilities.