by KerrickStaley
7 subcomments
- > At the time of writing, the fix has not yet reached stable releases.
Why was this disclosed before the hole was patched in the stable release?
It's only been 18 days since the bug was reported to upstream, which is much shorter than typical vulnerability disclosure deadlines. The upstream commit (https://github.com/gnachman/iTerm2/commit/a9e745993c2e2cbb30...) has way less information than this blog post, so I think releasing this blog post now materially increases the chance that this will be exploited in the wild.
Update: The author was able to develop an exploit by prompting an LLM with just the upstream commit, but I still think this blog post raises the visibility of the vulnerability.
by chromacity
7 subcomments
- This is cool work, but it's also somewhat unsurprising: this is a recurring problem with fancy, richly-featured terminal apps. I think we had at least ten publicly reported vulns of this type in the past 15 years. We also had vulnerabilities in tools such as less, in text editors such as vim, etc. And notably, many of these are logic bugs - i.e., they are not alleviated by a rewrite to Rust.
I don't know what to do with this. I think there's this problematic tension between the expectation that on one hand, basic OS-level tools should remain simple and predictable; but on the other hand, that of course we want to have pretty colors, animations, and endless customization in the terminal.
And of course, we're now adding AI agents into the mix, so that evil text file might just need to say "disregard previous instructions and...".
by WalterBright
3 subcomments
- Back in the PDP-10 days, one communicated with it using a terminal attached to it. One of my fellow students discovered that if you hit backspace enough times, the terminal handler would keep erasing characters before the buffer. Go far enough, and then there was an escape character (Ctrl-u?) that would delete the whole line.
Poof went the operating system!
by Drunk_Engineer
1 subcomments
- An almost identical security issue in iterm2 reported 6 years ago:
https://blog.mozilla.org/security/2019/10/09/iterm2-critical...
- Maybe I'm being unfair here, but it sounds like your complicated system (involving bootstrap scripts, a remote conductor agent, and "hijacking" the terminal connection with special escape sequences for command communication) has a subtle bug. Can't say I'm surprised, complexity breeds this sort of thing, especially when using primitives in ways they weren't really intended to be used.
> 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.
If I understand correctly, if a textfile (or any other source of content being emitted to the screen, such as server response banners) contains the special codes iTerm2 and the remote conductor use to communicate, they'll be processed and acted upon without verifying they actually came from a trusted remove conductor. Please correct me if I'm mistaken.
- iTerm2 author here. This could be used as a link in an exploit chain but by itself the claim in the title is massively overblown. I’m on a family vacation but I’ll release a fix when I get back.
- This sounds vaguely familiar. Wasn't iTerm2's SSH integration already the source of a relatively high profile CVE a while back?
⇒ https://nvd.nist.gov/vuln/detail/CVE-2025-22275
iTerm2 3.5.6 through 3.5.10 before 3.5.11 sometimes allows remote attackers to obtain sensitive information from terminal commands by reading the /tmp/framer.txt file. This can occur for certain it2ssh and SSH Integration configurations, during remote logins to hosts that have a common Python installation.
But I thought there was something more…
https://news.ycombinator.com/item?id=47811587 (this page) was in the tmux integration.
Maybe iTerm2 should try a little less hard on these integrations...
- Many years ago, terminal emulators used to allow keyboard rebindings via escape codes. This is why it was then common knowledge to never “cat” untrusted files, and to use a program to display the files instead; either a pager, like “less”, or a text editor.
- The title is sensationalist; cat is fine. What is unsafe is iTerm's ssh integration, which is pretty obviously unsafe, because it includes a side control channel that is not cleanly separated from the the data stream. Don't use it, use normal ssh, and all should be fine.
by f30e3dfed1c9
2 subcomments
- I think this article is horribly written. The second paragraph, in its entirety, reads:
> It turns out that it is NOT, if you use iTerm2.
And as far as I can tell, that is a vast overstatement. I think an actually true statement would be "It may not be, if you use iTerm2 and its optional 'Shell Integration' feature."
As far as I can tell, the "Shell Integration" feature under discussion is entirely optional and disabled by default. If it's not enabled, then there is no problem here. End of story.
Happy to be corrected if I'm wrong about this.
- There's been plenty of times that I catted a binary file and broke my terminal settings. Sometimes fixable by running `clear` (without being able to see what I'm typing), sometimes not.
And I know PuTTY has a setting for what string is returned in response to some control code, that iirc per standard can be set from some other code.
.
In general, in-band signaling allows for "fun" tricks.
.
+++
- What happens if instead of 'cat readme.txt' one does 'strings -a --unicode=hex readme.txt'? Does iTerm still monkey with it?
alias cat
cat='strings -a --unicode=hex'
- I used to use iTerm2. I had no idea it was doing all of this behind my back. That’s not what I want my terminal to do!
- Barely anyone mentioned the "AI agent angle", I mean the situation when an AI agent runs "cat readme.txt" a file with embedded instructions becomes a prompt injection attack. It is the same vulnerability class out-of-band data smuggled through an in-band channel, just targeting the different parser.
Terminal security guys have been fighting this for decades and the AI guys are about to rediscover it
- These categories of vulnerability are not new: https://dgl.cx/2023/09/ansi-terminal-security -- any time you take any untrusted data and do literally anything with it, you're at risk.
by CodesInChaos
3 subcomments
- I never understood why outputting unescaped data is viewed differently from generating unenclosed html.
Like why doesn't `println` in a modern language like rust auto-escape output to a terminal, and require a special `TerminalStr` to output a raw string.
- > A terminal used to be a real hardware device: a keyboard and screen connected to a machine, with programs reading input from that device and writing output back to it.
> A terminal emulator like iTerm2 is the modern software version of that hardware terminal.
That's the fundamental fatal flaw of emulating a bad dead hardware design. Are there any attempts to evolve here past all these weird in-band escape sequences leading cats to scratch your face?
by jdshaffer
2 subcomments
- Is it a problem with "cat" or a terminal problem?
If I wrote my own version of cat in C, simply reading and displaying a single TXT character at a time, wouldn't I see the same behavior?
- Older example of security mishaps in iTerm2's SSH integration: https://iterm2.com/downloads/stable/iTerm2-3_5_11.changelog
- > We'd like to acknowledge OpenAI for partnering with us on this project.
OpenAI: sponsor of the today's 0-day.
- I would prefer if these would not happen but that is the price for having a rich terminal. I donate to the author of iterm a small sum every month, I wish if he focused on the security for a while and tightened some bugs instead of pushing into AI related features
- More like iTerm2 is not safe
- Is ghostty vulnerable?
by connorboyle
1 subcomments
- If I were a GNU core utils maintainer, I would not be too happy with this post title
- SSH can do port forwards. Why does the conductor/iTerm2 interaction have to run over the normal shell at all?
- It is under 9front. There are not terminals, you wan windows with shells on it.
- I’ve said this for as long as I’ve been here on hacker news…
I want the terminal to be as dumb as possible.
I don’t want it to have any understanding of what it is displaying or anscribe any meaning or significance to the character characters it is outputting.
The first time apples terminal.app displayed that little lock icon at the ssh password prompt?
The hairs on the back of your neck should have stood up.
- Hmm. So the issue is, says the article, that:
> 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.
...which, the article strongly implies, but does not explicitly state, results in code execution on the local client machine.
But what about the case when it's working as designed, when the output does come from the remote conductor? It sounds like the server, where the conductor is running, is in that case trusted to execute arbitrary code on the client? Assuming the client doesn't use some sort of remote attestation, how can the remote conductor really be trusted?
- Glad I dumped iterm2 awhile ago after noticing it tends to have the highest energy impact next to my browser.
- I'm tired of iTerm2
- ssh conductor
- AI features almost forced on us until the community complained
- clickable links
I just want a dumb, reliable terminal. Is that too much to ask?
- Even click-baity titles are not safe.
by WesolyKubeczek
0 subcomment
- One reason I still prefer iTerm2 or Ghostty over Terminal.app is that it has way saner settings for what the word boundaries are, and it lets me select whole paths by double clicking on them. If there was a way to change it for the default terminal, I would just be using it.
by WhereIsTheTruth
0 subcomment
- > We'd like to acknowledge OpenAI for partnering with us on this project.
AD in disguise
- Wait, so... cat -v not considered harmful, then?
- Why does iterm2 need to know the shell and/or python versions on the other side? What happens if the othe side is a system that doesn't "understand" its bootstrap script (like a network switch or just some weird shell)?
What does iterm2 do with all that information, why does it need it? I don't get it
by DonHopkins
0 subcomment
- I used to leave a file called README in my public ftp directory that just said:
README: no such file or directory
One glorious day somebody finally sent me email complaining that they could not read the README file. I advised them to use "emacs README" instead of using cat. I was sorely disappointed they never sent me back a thank you note for correctly suggesting that emacs was the solution to their problem. It was my finest moment in passive aggressive emacs evangelism.
- With LLM tool use potentially every cat action could be a prompt injection
- > The final chunk (ace/c+aliFIo) works if that path exists locally and is executable.
Ah yes, the well known c+aliFIo shell script that every developer has. Inside the commonly used "ace" directory.
This article is sensationalist. And constructed by an LLM.
It's well known that cat'ing binary files can introduce weird terminal escape codes into the session.
Not surprised that iTerm's SSH integration is not security perfect.
- Programs trying to "execute" every piece of data thrown at them are a pest.
- [flagged]
- [flagged]
Hacker News