Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.calif.io

Post reply on HN
Print view View original

21–30 of 197 posts

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

#21

Post by lxgr »

saddist0 wrote: post #13
ezoe wrote: post #12

Earlier quoted context omitted.

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.

It’s a wrong way to look at things. Just because CIA can know your location (if they want to), would you share live location to everyone on the internet? LLM is a tool, but people still need to know — what where how.

Not sure if that's a great example. If there's a catastrophic vulnerability in a widely used tool, I'd sure like to know about it even if the patch is taking some time!

The problem with this is that the credible information "there's a bug in widely used tool x" will soon (if not already) be enough to trigger massive token expenditure of various others that will then also discover the bug, so this will often effectively amount to disclosure.

I guess the only winning move is to also start using AI to rapidly fix the bugs and have fast release cycles... Which of course has a host of other problems.

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

#22

Post by tasty_freeze »

ButlerianJihad wrote: post #9
TZubiri wrote: post #8

More 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!

I did this in 1985 on SOROC terminals we had in my first job out of college. However, it depended on the dip switch settings that were under a little door on top of the keyboard.

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

#23

Post by rezonant »

readthenotes1 wrote: post #19
jdshaffer wrote: post #14

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?

Give this one MS-DOS shell headline would be " why I never am using Microsoft again" or something dramatic like that. It is a problem in iterm, Apple's overlay, not in the cat program. Program. At least from Reading the article. That's what I got

It's actually a third party terminal emulator: https://iterm2.com/

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

#26

Post by im3w1l »

lxgr wrote: post #18
im3w1l wrote: post #10

Earlier quoted context omitted.

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…

> that may or may not be redirected to a file This is usually knowable. It's a different question whether cat should be doing that, though – it's an extremely low level tool. What's wrong with `less`? (Other than the fact that some Docker images seem to not include it, which is pretty annoying and raises the question as to whether `docker exec` should be filtering escape sequences...)

Sometimes you don't want to open stuff in a pager.

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

#30

Post by nostrademons »

chromacity wrote: post #17

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…

Makes me wonder if Claude Code has similar vulnerabilities, as it has a pretty rich terminal interface as well.

I think the real solution is that you shouldn't try to bolt colors, animations, and other rich interactivity features onto a text-based terminal protocol. You should design it specifically as a GUI protocol to begin with, with everything carefully typed and with well-defined semantics, and avoid using hacks to layer new functionality on top of previously undefined behavior. That prevents whatever remote interface you have from misinterpreting or mixing user-provided data with core UI code.

But that flies in the face of how we actually develop software, as well as basic economics. It will almost always be cheaper to adapt something that has widespread adoption into something that looks a little nicer, rather than trying to get widespread adoption for something that looks a little nicer.

Post reply on HN