"cat readme.txt" is not safe if you use iTerm2
blog.calif.io
"cat readme.txt" is not safe if you use iTerm2
1–10 of 197 posts
Re: "cat readme.txt" is not safe if you use iTerm2
#2[deleted]
Re: "cat readme.txt" is not safe if you use iTerm2
#3What 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'Re: "cat readme.txt" is not safe if you use iTerm2
#4What 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'
The whole "cat can hide unprintable characters" is such an old demo. I get this is a novel spin on which unprintable characters were doing but yeah, this was also my thought
Re: "cat readme.txt" is not safe if you use iTerm2
#5> 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.
Re: "cat readme.txt" is not safe if you use iTerm2
#6What 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'
The whole "cat can hide unprintable characters" is such an old demo. I get this is a novel spin on which unprintable characters were doing but yeah, this was also my thought
I'm just used to aliasing cat to strings after working around a lot of red-team penetration testers. They would prank each other and me all the time. Had to also watch out for this one [1].
Re: "cat readme.txt" is not safe if you use iTerm2
#7I 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.
Re: "cat readme.txt" is not safe if you use iTerm2
#8More like iTerm2 is not safe
Re: "cat readme.txt" is not safe if you use iTerm2
#9More like iTerm2 is not safe
A long, long time ago, it was literally possible to stuff the command buffer of a “dumb terminal” using ESC sequences and spoof keyboard input. So yeah, don’t count on ’cat’ being safe if your terminal isn’t!
Re: "cat readme.txt" is not safe if you use iTerm2
#10I 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.
I think the problem is that 1) You want to be able to write arbitrary bytes, including shell escape sequences into files. 2) You don't want to accidentally write terminal escape sequences to stdout. 3) Stdout is modeled as a file.
Consider cat. It's short for concatenate. It concatenates the files based to it as arguments and writes them to stdout, that may or may not be redirected to a file. If it didn't pass along terminal escapes, it would fail at its job of accurate concatenation.
Now I don't mean to dismiss your idea, I do think you are on the right track. The question is just how to do this cleanly given the very entrenched assumptions that lead us where we are.