Live data from Hacker News

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

blog.calif.io

101–110 of 197 posts

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

#101
post #80

I'm tired of iTerm2 - ssh conductor - AI features almost forced on us until the community complained - clickable links I just want a dumb, reliable terminal. Is that too much to ask?

Clickable paths is the unique feature of iTerm2 I use the most. It's called sematic history, for some reason, and converts a UNIX environment into something like an IDE. I let it trigger a bash script that opens my editor when I click a path in, e.g., a stack trace or in the output of a sequence of piped commands.

The developers of Kitty, Ghostty etc. are too much mouse haters to even acknowledge the possibility of this feature, so I'm stuck with iTerm2.

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

#102
post #37

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…

i think part of the problem is the archaic interface that is needed to enable feature rich terminal apps. what we really want is a modern terminal API that does not rely on in-band command sequences. that is we want terminals that can be programmed like a GUI, but still run in a simple (remote) terminal like before.

I shudder at the amount of backwards compatibility that would break. Is there anything more complicated than a simple input-output pipe (cat, grep, ...) that doesn't use terminal escapes? Even `ls --color` needs them!

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

#103

Earlier quoted context omitted.

LOL. It's a fact. It was discovered by a fellow student.

[flagged]

It's really not a very hard thing to imagine. The contents of the terminal screen were likely just a simple buffer in memory with the cursor position being a pointer into that memory. One missing bounds check and backspace starts messing with OS datastructures.

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

#105
post #32

Earlier quoted context omitted.

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

Terrible idea on every level

Run software in container. Software gets PTY. Boom, same issue

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

#106
post #80

I'm tired of iTerm2 - ssh conductor - AI features almost forced on us until the community complained - clickable links I just want a dumb, reliable terminal. Is that too much to ask?

then don't use it ? There are dozens of alternatives

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

#107
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?

You're talking nonsense. Backspace worked entirely fine on dumb terminals

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

#108

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.

Because terminal is not a browser but a screen. Outputting text isn't supposed to trigger anything aside from changing what's on screen.

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

#109
post #81
post #32

Earlier quoted context omitted.

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.

> 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. At a basic level there is no avoiding this. There is only one network interface in most machines and both the in-band and out-of-band data are getting serialized into it one way or another. See also WiFi preamble injection. These things…

>All of those have control data in the same stream under the hood.

Not true. For most binary protocols, you have something like . On magnetic media, sector headers used a special pattern that couldn't be produced by regular data [1] -- and I'm sure SSDs don't interpret file contents as control information either!

There may be some broken protocols, but in most cases this kind of problem only happens when all the data is a stream of text that is simply concatenated together.

[1] e.g. https://en.wikipedia.org/wiki/Modified_frequency_modulation#...

Post reply on HN