Get the top HN stories in your inbox every day.
mitchellh
samatman
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.
fmajid
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.
hnlmorg
I’m working on similar issues with my terminal emulator. So I’d very much like to be part of that conversation too.
aumerle
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.
mitchellh
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.
gigatexal
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.
aumerle
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?
rollcat
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.
SirHumphrey
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.
rollcat
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.
vacuity
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.
machinestops
Have you heard of Arcan? https://arcan-fe.com
rollcat
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.
throwaway1985s
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.
machinestops
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.
voxtech
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.
undefined
sevg
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.
aumerle
[flagged]
pwdisswordfishz
Oh, did he start actually fixing vulnerabilities instead of insisting they aren't there while repeatedly being given PoC exploits?
In case someone didn't know, the infamous Calibre bug report: https://bugs.launchpad.net/calibre/+bug/885027
sevg
It’s interesting how singularly passionate you are about Kitty, with almost all of your comments for the last year (or longer) being about Kitty.
Don’t you have something more interesting to do with your time than to find opportunities to say: nah Kitty is better ;)
I was just finding something to be impressed about, considering it has only just gone public and open source (as opposed to a mature project with established GitHub presence and flow of contributions).
throwawaykitten
FYI: aumerle is kitty's maintainer.
i don't know why he is talking about the project as if unaffiliated.
aumerle
Yup kitty revolutionized my terminal experience, hence the passion. I am sorry but since you seem to be passionate enough about ghostty to try to shill it in a article about a security vulnerability in it, I don't think you have a leg to stand on when it comes to complaining about my posts.
If you want to claim that ghostty is developed very rapidly it behoves you to do a little research and compare it against its peers before making that claim.
mitchellh
Kitty is a great terminal and Kovid does excellent work. I have a ton of respect for him. Ghostty (disclaimer: I’m the creator) could also be and I appreciate anyone who thinks so. There doesn’t have to be a winner/loser mentality!
The big picture is to get more people to use the terminal more for cases it’s good for. Infighting amongst people who already like terminals is counter productive, in my opinion.
throwawaykitten
it's good practice to note when you're the maintainer :)
still if you insist on direct comparison, ghostty addressed 5x as many issues in half the time
rurban
Actually usable now, or still entirely insecure?
wunderwuzzi23
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...
wslh
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>
MrLeap
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.
Things like this make me a little more cautious about standard out in general! More research to do.
Get the top HN stories in your inbox every day.
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.