I would say iTerm 2 has a pretty serious problem. A detailed analysis of the issue having a sentence implying it affects all users rather than many or most users is a minor problem.
Wait, hold on. iTerm 2's "conductor" is listening for the special escape sequences, whether or not you are using the shell integration features. The exploit affects all users, not just ones who have installed iTerm 2's shell integration.
I can't tell whether that's true or not. The article says:
> The rough model is:
> 1. iTerm2 launches SSH integration, usually through it2ssh.
> 2. iTerm2 sends a remote bootstrap script, the conductor, over the existing SSH session.
> 3. That remote script becomes the protocol peer for iTerm2.
How can I tell whether this "conductor" is running on the remote host or not?
I tried to reproduce this problem, following their instructions, but was unable to. I think but am not sure that's because my environment is pretty much nothing like one that would allow this to work.
For example, whether it's the default or not, my iTerm2 just doesn't have shell integration enabled. With my profile "Command:" set to "Login Shell," it doesn't look like I could enable it if I wanted to: "Load shell integration automatically" is disabled, apparently because "Automatic loading doesn't work with ksh."
The remote bootstrap script is not part of the exploit at all. It happens in iTerm locally without any ssh session. I just installed iTerm2 on a fresh machine (no shell integration installed), ran the exploit (generated the file with the python script, ran `cat readme.txt` locally), and it worked.
This is explained in the article in the "The core bug" section.
Cannot get it to work. Not worrying about it any more. Still think that the original article is horribly written, now think that their instructions are also.
