3 ms·
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 aff
by anamexis 6mo ago
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.
- f30e3dfed1c9 6mo agoI 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."
- anamexis 6mo agoThe 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.
- f30e3dfed1c9 6mo agoCannot 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.