Déjà vu: Ghostly CVEs in my terminal title | Hacker News Reader

Déjà vu: Ghostly CVEs in my terminal title

dgl.cx

208 pointsdgl55 comments

Just cross posting my lobsters post:

I want to say thanks to @dgl for reporting this, and this article is also expertly written.

I also have to say for me personally its quite embarrassing because as I told @dgl when he reported this: I’ve studied his work before and made it a note to test Ghostty against his past discoveries prior to release. And I… quite simply forgot. I didn’t make an issue for myself so it slipped away and here I am with egg on my face. I’m sorry!

But, I appreciate @dgl for the security report, reviewing the fix, and continuing to be an active user of the terminal. I also shared with him some broader thoughts on terminal security in general. Addressing terminal security in a more fundamental way is one of the first proposals I want to make regarding terminal innovation.

My thinking is still too early and under-researched for a formal proposal. But my general feeling having built a terminal over the past 2 years is that the security surrounding escape sequences is fundamentally flawed and poking one by one at these sequences to try to make them individually safe doesn’t feel like the right long term solution.

The surface area is too large and the complexity of some of the newer sequences too high (i.e. Kitty Graphics) to be confident in secure implementations. DoS is far too easy with terminals (Ghostty has a handful of known DoS attacks, but so does pretty much every other terminal I know of). And some legacy sequences are just kind of shocking to have immediately available. For example, DECCOLM is available in macOS Terminal.app. If you issue a DECCOLM (CSI ? 3 h I believe), Terminal.app will physically resize the window and lock it to 132 columns. You can very easily crash Terminal.app at anytime by sending enough of these (a DoS attack). There are many more.

Part of my thinking is trying to design a mechanism that can effectively create something akin to either CPU protection rings or OpenBSD’s pledge() syscall. Whatever the mechanism, the general idea is: reduction of capability.

For example, it makes sense for a shell to be extremely powerful. It’s literally a code execution device. However, it doesn’t make much sense for cat to be able to execute arbitrary escape sequences (which it does today in any terminal). Whether it is the shell or cat itself, something should be able to tell a terminal: “hey, only execute some subset of escape sequences (or none at all).” For cat, that might be none or perhaps just SGR sequences (styles, colors, etc.). The insecurity of cat-ing or tail-ing any form of data that could contain user-generated data is hopefully well known at this point…

As I said before, this thinking is all still very raw and I don’t have anything concrete to proposal. I want to share this because I want folks to know that I’m thinking about it, and perhaps others may be interested in thinking about it with me… if so, please contact me. I’ve already shared this line of thinking with @dgl as well.

You proposal does not address this issue since shells would still need full privileges.

This entire class of exploits (query responses with user controlled data leading to shells executing commands) would be removed if shells just moved to using the kitty keyboard protocol with all key events represented as escape codes and implemented a full escape code parser for data received form the terminal. You cannot embed an escape code inside another, or while technically you can, it is trivial to implement a security policy of disallowing these in both terminals and shells. Then barring implementation bugs in the escape code parser (which can easily be shipped as a standalone native code library) you dont have this entire class of issues and the associated one that the bracketed paste hack was created to address.

I believe it could. A shell could reduce capability by default for all executed shell scripts (file or inline on the prompt) and require opt in to not do this. Something akin to a umask of sorts. It’d break exceedingly few real scripts. (Hand waving a lot here with the “opt in” mechanism to avoid that being scripted but I have ideas)

Also note my thoughts (very much not even close to being a proposal) are very raw. Inviting this kind of discussion is exactly what I hope to do :)

Reduction of capability in general is not intended to address all class of security issue. For example you’d still want unsafe paste detection (to detect newlines or attempted bracketed paste escapes) on a prompt line.

But I think having a mechanism to eliminate the possibility of entire class of actions without wholesale disabling them in the terminal emulator is a desirable property. Right now a lot of these features are mostly on/off.

So if I am to understand your proposal more concretely it is something like implement an escape code that the shell can use to turn off all other escape codes (presumably with some kind of listing mechanism) and then have the shell do that before launching any third party script/program/function? How would the shell know which escape codes the program it is running needs?

I can, kind of, see the utility of a pledge() type system within a single program, but in a shell, whose whole job is basically running programs it knows nothing about beyond their name? How would that work?

Sorry to be a broken record but I have no “proposal” whatsoever. It’s more of an information sharing and seeking discussion. I don’t know what I want yet except that I think we can do better. The end result could be that it’s all a terrible idea and that’s okay, but hopefully something comes out of it eventually.

Id love to continue this discussion, but I think HN threads probably aren’t the right medium. If you’d like I can email you or we can schedule a call. I’m not trying to seek privacy, I’d be happy for any to be recorded or shared publicly, I just don’t find HN to be a good place if you really want to dive into this!

Of course, I didn't mean to put you in a spot. We can always continue this later once your thoughts have matured. Sadly I have an extremely full schedule so I dont think I have the badwidth to noodle on this at this stage but if and when you have something more concrete please do post it somewhere public and I will try to contribute to the discussion.

Appreciate it! <3

But strangely have a lot of time to post here

And a lot of time to post only about kitty XD

aumerle is Kovid Goyal, the author of kitty.

Thanks for calling this out.

I'll remember his comments as an example of how much pettiness both drives and undermines OSS.

I've discussed with Mitchell a bit in the past on this, but there are a few ways to opt in to this. First, let's imagine there is some escape sequence that tells the terminal to ignore some set of escape sequences.

1. The shell could have a keybind (say, ctrl+enter) which runs the command with (for example) only styling enabled (CSI m sequences).

2. You could write a wrapper around any program to do the same. The shell doesn't need to know anything about the system, but instead you have a wrapper that disables and then reenables said sequences.

3. A program itself can opt in by turning on the feature at launch. This allows CLI / TUI developers to "safeguard" their programs from malicious attacks.

Whatever you all do please continue the fight. I love love love the ergonomics of the terminal. It feels like a super power for me and is crucial to my work flow. If someone told my CTO that terminals are an attack vector they might do something silly and ban them — might sound crazy but management has gone crazier things.

I’m working on similar issues with my terminal emulator. So I’d very much like to be part of that conversation too.

Shouldn't all these control-plane operations be moved to ioctl instead, like TIOCSWINSZ? Of course, getting all terminal emulators and TUI programs to use them would be a formidable migration undertaking.

It's not just Kitty graphics, the Kitty Keyboard Protocol is a DOS waiting to happen, and Goyal with his customary charm is very hostile to the idea of correcting his mistake: https://github.com/kovidgoyal/kitty/issues/7749

Short version: as defined, Mode 16 can deliver many megabytes of CSI parameters before the parser ever sees the `u` telling it what it's parsing. Since this is violently different from any other CSI code ever proposed or implemented, it cannot be parsed using any technique or parser which expects sane behavior.

This isn't the only problem with KKB, it must be deprecated and replaced.

I really wish that 1% of the sustained effort that is currently being devoted to building terminal emulators and TUI applications was collectively redirected at researching a better future to fill this niche.

Terminal emulators and TUI applications belong with the DMG Gameboys, Commodore 64's, and DOSBoxes: as a historical curiosity and something for the enthusiasts to enjoy after hours. But we've come to rely on them almost to the point where they're being fetishised; most of us using this technology nowadays aren't even questioning its negative impact.

We need better command line / REPL environments. We need better cross-platform GUI toolkits. We need better remote access. And we need to let go of the TV teletype.

It's X11/systemd/ipv4 problem. People agreeing there is a problem doesn't mean that any single solution will be accepted. With terminals you have a system that works with anything from HPC-s to serial devices. An alternative would probably need to drop support for something, meaning congratulations: The number of standards increased by 1 - probably 2 by the time that people unsupported by the modern alternative decide that they too would like something new.

The current effort can at least be pointed towards something.

I think you're both right in that we need standards, and we'll get them but with fractures, but at the same time we could try harder to reduce the incidence of fractures. Because at the end of the day this is all a social problem, and social problems can only be fixed by the society coming together.

I don't think we need a new standard (the web is already a standard, and PWAs/Electron build on top of it), we simply need better incentives/trade-offs for people who would like to write portable software, but are stuck between TUI and a hard place.

I'm weirdly attracted to Tk (with Tcl or Tkinter). It's not shiny, but it's very practical.

1% of the sustained effort being spent on terminal emulators would be like a third of an engineer, so I have some great news for you.

Have you heard of Arcan? https://arcan-fe.com

Yes, I've been following it for a while - it's exactly the kind of research that I had on my mind. I don't necessarily agree with some of the design choices (I don't think we need a middle layer underneath VT100 emulation to make TUI apps, TUI is IMHO just terrible as a concept to begin with), but SHMIF has the mark of a battle-tested protocol, and many other concepts are very interesting.

I appreciate the commitment it has to backwards compatibility - the TUI apps are better by virtue of running on top of Arcan's layer, with no changes.

They treat CLIs as a subclass of TUIs. Underneath it all it is just a high-level decoupling API to replace ncurses/readline/.... The output becomes a window with a packed-text buffer format. You can mix and match graphical windows with TUI(CLI) ones in the same client.

I’m impressed with how many bugs (security and otherwise) have been fixed and new features included [0] in the 1.0.1 release, considering the first public release (1.0) was only 5 days ago.

[0]: https://ghostty.org/docs/install/release-notes/1-0-1

An important new attack vector are actually CLI LLM applications.

During prompt injection an attacker can cause such ANSI escape codes to be emitted!

Check out this post to learn more about Terminal DiLLMa and how to mitigate it:

https://embracethered.com/blog/posts/2024/terminal-dillmas-p...

It is worth mentioning my prior report on Bugtraq from 1999 [1], which predates that Bugtraq 2003 report. I recall there were earlier reports elsewhere, though I'm uncertain if I made my exploit publicly available. What stood out about this type of exploit was that it could be triggered simply by a banner in FTP/Telnet/SSH.

[1] "Kvt bug": <https://seclists.org/bugtraq/1999/Sep/432>

This is fascinating. I was just playing around with this pretty printing library in .net and I wondered how security critical such a thing was, and whether or not it could be trusted.

https://spectreconsole.net/

Things like this make me a little more cautious about standard out in general! More research to do.

Reply on news.ycombinator.com