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!
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.
show comments
Drunk_Engineer
An almost identical security issue in iterm2 reported 6 years ago:
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...".
show comments
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!
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'
show comments
SrslyJosh
> We'd like to acknowledge OpenAI for partnering with us on this project
Thanks, saved me some reading time.
delduca
Is ghostty vulnerable?
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?
show comments
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.
show comments
TZubiri
More like iTerm2 is not safe
show comments
valleyer
Wait, so... cat -v not considered harmful, then?
anthk
It is under 9front. There are not terminals, you wan windows with shells on it.
einpoklum
Even click-baity titles are not safe.
holoduke
With LLM tool use potentially every cat action could be a prompt injection
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!
> 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.
An almost identical security issue in iterm2 reported 6 years ago:
https://blog.mozilla.org/security/2019/10/09/iterm2-critical...
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...".
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!
What happens if instead of 'cat readme.txt' one does 'strings -a --unicode=hex readme.txt'? Does iTerm still monkey with it?
> We'd like to acknowledge OpenAI for partnering with us on this project
Thanks, saved me some reading time.
Is ghostty vulnerable?
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?
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.
More like iTerm2 is not safe
Wait, so... cat -v not considered harmful, then?
It is under 9front. There are not terminals, you wan windows with shells on it.
Even click-baity titles are not safe.
With LLM tool use potentially every cat action could be a prompt injection