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

121–130 of 197 posts

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

#121

Post by zrm »

rep_lodsb wrote: post #120
zrm wrote: post #116

Earlier quoted context omitted.

The header and length of the payload are control data. It's still being concatenated even if it's binary. A common way to screw that one up is to measure the "length of payload" in two different ways, for example by using the return value of strlen or strnlen when setting the length of the payload but the return value of read(2) or std::string size() when sending/writing it or vice versa. If the data unexpectedly con…

From your previous post: >It's user data in JSON in an HTTP stream in a TLS record in a TCP stream in an IP packet in an ethernet frame. Then it goes into a SQL query which goes into a B-tree node which goes into a filesystem extent which goes into a RAID stripe which goes into a logical block mapped to a physical block etc. All of those have control data in the same stream under the hood. It's true that a lot of cod…

> There is almost certainly no way that writing a "magic" byte sequence to a file will cause the storage device to misinterpret it as control data and change the mapping of logical to physical blocks.

Which is also what happens if you use parameterized SQL queries. Or not what happens when one of the lower layers has a bug, like Heartbleed.

There also have been several disk firmware bugs over the years in various models where writing a specific data pattern results in corruption because the drive interprets it as an internal sequence.

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

#122

Post by rep_lodsb »

skissane wrote: post #94
harrall wrote: 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…

For this use case, there would also have to be an extension to the SSH protocol to send such out-of-band information. Maybe this already exists and isn't used?

The broader problem with terminal control sequences didn't exist on Windows (until very recently at least), or before that DOS and OS/2. You had API calls to position the cursor, set color/background, etc. Or just write directly to a buffer of 80x25 characters+attribute bytes.

But Unix is what "serious" machines -a long time ago- used, so it has become the religion to insist that The Unix Way(TM) is superior in all things...

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

#123

Post by shakna »

ButlerianJihad wrote: post #67
WalterBright wrote: post #66

Earlier quoted context omitted.

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

[flagged]

I'd call it even likely, with most of the flat memory OSs of the past. We are talking 50 years ago.

C64 had a flat memory map, where the input came as the first address in range 0 to DFFF. What came after that? The kernel. So if you wrote too much data into the input address space, and the overflow wasn't caught, you'd overwrite the OS there, too. And writing into the IO table was common, because it was faster to access.

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

#124

Post by alienbaby »

yjftsjthsd-h wrote: post #72
tbrownaw wrote: post #51

There's been plenty of times that I catted a binary file and broke my terminal settings. Sometimes fixable by running `clear` (without being able to see what I'm typing), sometimes not. And I know PuTTY has a setting for what string is returned in response to some control code, that iirc per standard can be set from some other code. . In general, in-band signaling allows for "fun" tricks. . +++

> Sometimes fixable by running `clear` (without being able to see what I'm typing), sometimes not. Two tips, if I may: Ctrl-l is easier to type. And `reset` is equally hard to type on a broken terminal, but more effective.

Stty sane has also got me out of this hole many times

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

#125

Post by miki123211 »

KerrickStaley wrote: post #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 th…

So this bug just proves my thesis about shortening update windows.

You may need Claude Mythos to find a hard-to-discover bug in a 30-year-old open source codebase, but that bug will eventually be patched, and that patch will eventually hit the git repo. This lets smaller models rediscover the bug a lot more easily.

I won't be surprised if the window between a git commit and active port scans shrinks to hours or maybe even minutes in the next year or two.

This is where closed source SaaS has a crucial advantage. You don't get the changelog, and even if you did, it wouldn't be of much use to you after the fix is deployed to production.

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

#126

Post by ButlerianJihad »

shakna wrote: post #123
ButlerianJihad wrote: post #67

Earlier quoted context omitted.

[flagged]

I'd call it even likely, with most of the flat memory OSs of the past. We are talking 50 years ago. C64 had a flat memory map, where the input came as the first address in range 0 to DFFF. What came after that? The kernel. So if you wrote too much data into the input address space, and the overflow wasn't caught, you'd overwrite the OS there, too. And writing into the IO table was common, because it was faster to acc…

By using a backspace key‽

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

#127

Post by WesolyKubeczek »

em-bee wrote: post #68
kps wrote: post #62

Earlier quoted context omitted.

A network-transparent graphics protocol? Who would ever think of such a thing?

that's actually not what i am after. what i envision is a graphical terminal, that is a terminal that uses graphic elements to display the output. consider something like grep on multiple files. it should produce a list of lines found. the graphical terminal takes that list and displays it. it can distinguish the different components of that list, the filenames, the lines matched, the actual match, etc. because it ca…

We call those “web browsers” nowadays, they even can execute untrusted code to make your UI livelier…

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

#128

Post by WesolyKubeczek »

eqvinox wrote: post #92

This sounds vaguely familiar. Wasn't iTerm2's SSH integration already the source of a relatively high profile CVE a while back? ⇒ https://nvd.nist.gov/vuln/detail/CVE-2025-22275 iTerm2 3.5.6 through 3.5.10 before 3.5.11 sometimes allows remote attackers to obtain sensitive information from terminal commands by reading the /tmp/framer.txt file. This can occur for certain it2ssh and SSH Integration configurations, duri…

Which is why I’m also wary of the ghostty’s integration that is supposed to inject its terminfo when you ssh in.

How about bloody no and working with upstream ncurses to update the terminfo database?

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

#129

Post by WesolyKubeczek »

tbrownaw wrote: post #51

There's been plenty of times that I catted a binary file and broke my terminal settings. Sometimes fixable by running `clear` (without being able to see what I'm typing), sometimes not. And I know PuTTY has a setting for what string is returned in response to some control code, that iirc per standard can be set from some other code. . In general, in-band signaling allows for "fun" tricks. . +++

Ask me how I know what “tput reset” does.

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

#130

Post by StilesCrisis »

rep_lodsb wrote: post #120
zrm wrote: post #116

Earlier quoted context omitted.

The header and length of the payload are control data. It's still being concatenated even if it's binary. A common way to screw that one up is to measure the "length of payload" in two different ways, for example by using the return value of strlen or strnlen when setting the length of the payload but the return value of read(2) or std::string size() when sending/writing it or vice versa. If the data unexpectedly con…

From your previous post: >It's user data in JSON in an HTTP stream in a TLS record in a TCP stream in an IP packet in an ethernet frame. Then it goes into a SQL query which goes into a B-tree node which goes into a filesystem extent which goes into a RAID stripe which goes into a logical block mapped to a physical block etc. All of those have control data in the same stream under the hood. It's true that a lot of cod…

I distinctly remember bugs with non-Hayes modems where they would treat `+++ATH0` coming over the wire as a control, leading to BBS messages which could forcibly disconnect the unlucky user who read it.

In this particular case, IIRC Hayes had patented the known approach for detecting this and avoiding the disconnect, so rival modem makers were somewhat powerless to do anything better. I wonder if such a patent would still hold today...

Post reply on HN