Omarchy has changed its Kitty configuration after a security issue was identified with allow_remote_control yes.

That setting allows Kitty’s remote-control protocol to accept commands from terminal output, meaning untrusted output could potentially execute commands as the current user. Kitty itself defaults this setting to no; the exposure came from Omarchy explicitly enabling it so other parts of the desktop could query the active terminal’s working directory.

The change disables remote control by default and migrates existing explicit yes settings to no. Users affected by the migration need to fully close and reopen Kitty, as existing processes remain exposed until they exit.

There is a small trade-off: Omarchy can no longer reliably determine the active Kitty tab/pane’s working directory via its socket, so new terminal or Files launches may occasionally fall back to the home directory.

The associated migration tests reportedly pass, although no live Kitty test was run in the test environment.

  • Eager Eagle@lemmy.world
    link
    fedilink
    English
    arrow-up
    5
    ·
    edit-2
    14 hours ago

    That does not allow remote code execution. An attacker still needs a vector like an SSH session to be able to control kitty. And at that point, if they already have a shell session, they don’t need kitty to do damage.

    edit: giving access to other programs is not remote execution, but obviously not a good default.

    • starblursd@lemmy.zip
      link
      fedilink
      English
      arrow-up
      6
      ·
      17 hours ago

      It actually also allows other programs to execute code through Kitty, example if you cat a file that has escapes in it. It would allow Kitty to execute that code when you never intended it… But like why does kitty even have that as a feature? But they’ve since updated the config to be set to socket only instead of yes

      • dizuane@sh.itjust.works
        link
        fedilink
        arrow-up
        4
        ·
        16 hours ago

        Having the feature seems pretty in line with the general Linux philosophy. Let the user decide, even if that means they screw it up. Same reason you can muck up an install by just running updates on storage that doesn’t have enough room to do so. It’s up to the end user to understand, verify, and choose to execute.