Live data from Hacker News

"cat readme.txt" is not safe if you use iTerm2

blog.calif.io

91–100 of 197 posts

Re: "cat readme.txt" is not safe if you use iTerm2

#91

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 w…

Makes me wonder if Claude Code has similar vulnerabilities, as it has a pretty rich terminal interface as well. I think the real solution is that you shouldn't try to bolt colors, animations, and other rich interactivity features onto a text-based terminal protocol. You should design it specifically as a GUI protocol to begin with, with everything carefully typed and with well-defined semantics, and avoid using hacks…

Spoofing the source of a string that controls colors and animations isn’t really a problem. Spoofing the source of a string that get executed is in an entirely different league.

Re: "cat readme.txt" is not safe if you use iTerm2

#92
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...

Re: "cat readme.txt" is not safe if you use iTerm2

#93
post #92

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, duri…

multiple times

Re: "cat readme.txt" is not safe if you use iTerm2

#94
post #32

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 w…

Well all these bugs (iTerm2’s, prompt injection, SQL injection, XSS) are one class of mistake — you sent out-of-band data in the same stream as the in-band data. If we can get that to raise a red flag with people (and agents), people won’t be trying to put control instructions alongside user content (without considering safeguards) as much.

This could be fixed with an extension to the kernel pty subsystem

Allow a process to send control instructions out-of-band (e.g. via custom ioctls) and then allow the pty master to read them, maybe through some extension of packet mode (TIOCPKT)

Actually, some of the BSDs already have this… TIOCUCNTL exists on FreeBSD and (I believe) macOS too. But as long as Linux doesn’t have it, few will ever use it

Plus the FreeBSD TIOCUCNTL implementation, I think it only allows a single byte of user data for the custom ioctls, and is incompatible with TIOCPKT, which are huge limitations which I think discourage its adoption anyway

Re: "cat readme.txt" is not safe if you use iTerm2

#95
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

Re: "cat readme.txt" is not safe if you use iTerm2

#97
post #60
post #48

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.

What you’re describing would be a completely unusable terminal. You’d lose things as basic as the backspace key. And what’s wrong with Terminal.app indicating when it’s suppressing output?

Terminal.app does not suppress output in my example.

The ssh command switches the terminal into no-echo mode with termios flags.

Terminal.app, being clever, watches for disabled echo (among other things) and assumes a password is being entered and displays the key icon and enables Secure Event Input.

I don't want Terminal.app to be clever.

Re: "cat readme.txt" is not safe if you use iTerm2

#98
post #52

> 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…

The bug is in a feature of iTerm2 that the "bad dead hardware design" did not have. The "bad dead hardware design" was much simpler and less ambitious in scope.

If iTerm2 had stuck to emulating a VT220 this issue would not have existed. If anything it's the idea that it should "evolve" that's flawed. Something like a VT220 was designed for a kind of use that is surprisingly relevant still. I think doing something significantly different warrants designing something significantly different, not merely "evolving" existing solutions to other problems by haphazardly shoehorning new features into them without paying attention to security implications.

This is only the latest of several rather serious vulnerabilities in iTerm2's SSH integration.

Re: "cat readme.txt" is not safe if you use iTerm2

#99
post #69
post #55

Earlier quoted context omitted.

Yes. It’s called the X Window System and it’s been around since the ‘80s. Also the problem here isn’t that iterm2 is trying to emulate terminals, it’s that it’s trying to do something more over the same network connection without making changes to the ssh protocol.

X11 or any network transparent graphics protocol doesn't solve the problems that a terminal solves. how do you pipe data through multiple applications in one command using a GUI for example? nobody has been able to solve that in a practical way yet. what we really want is being able to pipe semantic data that can be output to some kind of graphical device/interface that uses that semantic information to display the d…

> X11 or any network transparent graphics protocol doesn't solve the problems that a terminal solves. how do you pipe data through multiple applications in one command using a GUI for example? nobody has been able to solve that in a practical way yet.

It seems to me that you are conflating the role of the terminal with the role of the shell. The terminal accepts streams of text and commands to instruct the terminal, so that software can accept input and present output. It doesn't fundamentally need to be aware of the concepts of pipes and commands to do that.

Of course, that doesn't stop iTerm2 from doing RCE by design, but at a conceptual level this is not a problem inherent to a terminal.

Re: "cat readme.txt" is not safe if you use iTerm2

#100

> 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 th…

[dead]
Post reply on HN