MAD Bugs: Even "cat readme.txt" is not safe
4 points by ahobson
4 points by ahobson
The bug is a trust failure. iTerm2 accepts the SSH conductor protocol from terminal output that is not actually coming from a trusted, real conductor session. In other words, untrusted terminal output can impersonate the remote conductor.
What is a "trusted, real conductor session"? Just because a session is "real" doesn't mean I trust the server on the other end (and it would be a bit insane to "trust" every random server I connect to).
By the way, is the article generated by an LLM too, or is it just bad writing? This was so obnoxious to read; there's so much padding. "The fake OSC 135 messages are minimal but precise"? Who writes like that? "That string is not arbitrary"? No shit, the exploit isn't just a random string?
This write-up does a great job burying the lede instead of explaining the actual issue. As far as I understand from reading the patch:
The issue is that iTerm2 communicates with the ssh integration script on the other side by dumping "raw" base64, split into lines, to the terminal (see encode()).
The base64 string can contain some attacker-controlled data. And, because it's split into lines, they can prepare things such that the last base64-encoded line contains a string that will be a valid path to an executable, relative to where you ran cat from.
(It probably doesn't have to be the last line either, but that's what they went with here. They also did not explain any of this - you know, the actual important part of the exploit - at all. Is the point of this article to actually explain what was found, or to just brag about finding a bug with some extra padding? ffs...)
The particular approach they went with here was the following:
execLoginShell(). The way they achieve this is by "failing" the python version check, but there's presumably a lot of ways to do it.sshargs set in the handshake by the server. They set that to something that will encode as a valid path. I don't know if there's anything special about sshargs there.But, you know, the article instead helpfully explained that iTerm2 in fact encodes run <padding><magic-bytes>. What padding? What magic-bytes? What?
I miss reading articles written by humans. I wish there was a way to tell up-front that nobody put care into this before wasting my time on it.
So the title should really be: iTerm2's ssh is not safe. But running cat something-or-another is perfectly fine?
An escape sequence output to the terminal can trick iTerm2 into thinking its SSH integration has been used, this can happen at any point, so doesn’t depend on what the user does.
This class of exploit isn’t new (I have a whole write up). “cat” is one way to output raw bytes to the terminal, “curl” can do the same, unfortunately it’s hard to change tools, users need to learn to use cat -v or pipe to a pager. (In zsh you can use < file which does the right thing with a pager and is less typing.)
They sure didn't wait very long!