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

Bender

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'

KerrickStaley

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

CodesInChaos

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.

TZubiri

More like iTerm2 is not safe

holoduke

With LLM tool use potentially every cat action could be a prompt injection

jdshaffer

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?

einpoklum

Even click-baity titles are not safe.

chromacity

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...".

Drunk_Engineer

An almost identical security issue in iterm2 reported 6 years ago: https://blog.mozilla.org/security/2019/10/09/iterm2-critical...

anthk

It is under 9front. There are not terminals, you wan windows with shells on it.

SrslyJosh

> We'd like to acknowledge OpenAI for partnering with us on this project Thanks, saved me some reading time.

valleyer

Wait, so... cat -v not considered harmful, then?

delduca

Is ghostty vulnerable?

bananaboy

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!

WalterBright

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!

DonHopkins

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.

rkagerer

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.

rsync

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.

tbrownaw

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. . +++

eviks

> 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 cat s to scratch your face?