[HN Gopher] Deja vu: Ghostly CVEs in my terminal title
___________________________________________________________________
Deja vu: Ghostly CVEs in my terminal title
Author : dgl
Score : 188 points
Date : 2024-12-31 23:47 UTC (23 hours ago)
(HTM) web link (dgl.cx)
(TXT) w3m dump (dgl.cx)
| sevg wrote:
| 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
| aumerle wrote:
| If that impresses you, you will have your socks blown off by:
| https://sw.kovidgoyal.net/kitty/changelog/#detailed-list-of-...
| sevg wrote:
| 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).
| aumerle wrote:
| 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.
| sevg wrote:
| What a strange reply.
|
| Kitty has been my terminal for years. I haven't even used
| ghostty. I'm not shilling anything. Good grief. Try
| looking in a mirror.
|
| I was making a good faith comment just adding something
| positive. No need to turn it into a war. It's strange
| (and just wrong) that you think I need to review the
| development velocity of all other projects before being
| impressed by something. Actually, no. To be impressed by
| the rainbow outside my window, I need not have seen and
| reviewed all other rainbows.
| throwawaykitten wrote:
| FYI: aumerle is kitty's maintainer.
|
| i don't know why he is talking about the project as if
| unaffiliated.
| sevg wrote:
| Oh boy, that actually explains a lot! And this whole time
| he was accusing _me_ of being insincere XD
|
| Also explains why he suddenly had no time to talk further
| when ghostty's author offered to have a call elsewhere in
| this thread. Just here to advertise his terminal.
|
| I must say, I quite like how ghostty's author has
| conducted himself. Might give ghostty a try once it's
| packaged for my distro and first few rounds of bugfixes
| are in.
| fmajid wrote:
| Like Julius Caesar, who used to write about himself in
| the third person laudative demonstrative ("ille")?
| saagarjha wrote:
| Like, this is Kovid? This has to be a violation of the
| site guidelines.
| mitchellh wrote:
| 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.
| pwdisswordfishz wrote:
| 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
| rurban wrote:
| Actually usable now, or still entirely insecure?
| throwawaykitten wrote:
| 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
| mitchellh wrote:
| 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.
| aumerle wrote:
| 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 wrote:
| 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.
| aumerle wrote:
| 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?
| mitchellh wrote:
| 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!
| aumerle wrote:
| 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.
| mitchellh wrote:
| Appreciate it! <3
| moderation wrote:
| But strangely have a lot of time to post here
| sevg wrote:
| And a lot of time to post only about kitty XD
| remram wrote:
| aumerle is Kovid Goyal, the author of kitty.
| rockorager wrote:
| 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.
| gigatexal wrote:
| 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.
| hnlmorg wrote:
| I'm working on similar issues with my terminal emulator. So I'd
| very much like to be part of that conversation too.
| fmajid wrote:
| 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.
| samatman wrote:
| 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.
| rollcat wrote:
| 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 wrote:
| 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.
| vacuity wrote:
| 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.
| voxtech wrote:
| 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.
| machinestops wrote:
| Have you heard of Arcan? https://arcan-fe.com
| wslh wrote:
| 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>
| wunderwuzzi23 wrote:
| 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...
| MrLeap wrote:
| 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.
___________________________________________________________________
(page generated 2025-01-01 23:01 UTC)