Even "cat readme.txt" is not safe

Posted by arkadiyt 3 hours ago

Counter17Comment10OpenOriginal

Comments

Comment by KerrickStaley 55 minutes ago

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

Comment by ezoe 14 minutes ago

I guess traditional moratorium period for vulnerability publication is going to be fade away as we rely on AI to find it.

If publicly accessible AI model with very cheap fee can find it, it's very natural to assume the attackers had found it already by the same method.

Comment by CodesInChaos 47 minutes ago

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.

Comment by im3w1l 32 minutes ago

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.

Comment by TZubiri 40 minutes ago

More like iTerm2 is not safe

Comment by ButlerianJihad 37 minutes ago

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!

Comment by Bender 2 hours ago

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'

Comment by halJordan 57 minutes ago

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

Comment by Bender 51 minutes ago

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

[1] - https://thejh.net/misc/website-terminal-copy-paste

Comment by 2 hours ago

Comment by holoduke 23 minutes ago

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