Just cross posting my lobsters post:<p>I want to say thanks to @dgl for reporting this, and this article is also expertly written.<p>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!<p>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.<p>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.<p>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.<p>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.<p>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…<p>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.
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.<p>Terminal emulators <i>and</i> 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.<p>We need <i>better</i> command line / REPL environments. We need <i>better</i> cross-platform GUI toolkits. We need <i>better</i> remote access. And we need to let go of the TV teletype.
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.<p>[0]: <a href="https://ghostty.org/docs/install/release-notes/1-0-1" rel="nofollow">https://ghostty.org/docs/install/release-notes/1-0-1</a>
An important new attack vector are actually CLI LLM applications.<p>During prompt injection an attacker can cause such ANSI escape codes to be emitted!<p>Check out this post to learn more about Terminal DiLLMa and how to mitigate it:<p><a href="https://embracethered.com/blog/posts/2024/terminal-dillmas-prompt-injection-ansi-sequences/" rel="nofollow">https://embracethered.com/blog/posts/2024/terminal-dillmas-p...</a>
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.<p>[1] "Kvt bug": <<a href="https://seclists.org/bugtraq/1999/Sep/432" rel="nofollow">https://seclists.org/bugtraq/1999/Sep/432</a>>
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.<p><a href="https://spectreconsole.net/" rel="nofollow">https://spectreconsole.net/</a><p>Things like this make me a little more cautious about standard out in general! More research to do.