Bug#1034875: kitty: Should not handle application/x-sh mime type by executing the script
On Wed, Apr 26, 2023 at 02:50:47PM +0200, Raphael Hertzog wrote: > Executing the script as default open action is IMO a very bad idea > because what you get by email is largely to not be trusted so I would > suggest that kitty be modified to not execute scripts in its URL > launcher mode (or that it gets some interactive confirmation from the > user before executing it). Upstream has added support for prompting if a file is executable[0]. However, the current upstream version of kitty has rewritten all of its kittens in go, so the changes aren't trivially backported. For bookworm, I'm going to stop installing kitty-open.desktop, by default. Install, I will ship it under /usr/share/doc/kitty/examples and add a note to README.Debian about it. [0]: https://github.com/kovidgoyal/kitty/commit/537cabca710f64b838d3b8b1dc986db596fb29d4 Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#1034875: kitty: Should not handle application/x-sh mime type by executing the script
On Sat, May 06, 2023 at 04:07:56PM +0200, Gabriel Corona wrote: > Hi, > > > In the mean time, it's probably a good idea to drop > > "application/x-sh;application/x-shellscript" from the list of supported > > mime type to limit the risk. (I assume that even with "text/plain" and a > > .sh file extension or a shebang, kitty might still decide to execute the > > script... so the issue is not entirely fixed, but it reduces the number > > of > > cases where "kitty +open" is invoked on shell scripts) > > Indeed, you can use a file with MIME type such as text/ascii or > x-scheme-handler/kitty and a .tool file extension and it will be executed > through kitty. > > Affected software include: mail clients (mutt, Thunderbird [3,4]), browsers > (Firefox [1,2]), PDF viewers (Okular [5]). > > [1] https://www.gabriel.urdhr.fr/img/kitty-firefox1.png > [2] https://www.gabriel.urdhr.fr/img/kitty-firefox2.png > [3] https://www.gabriel.urdhr.fr/img/kitty-thunderbird1.png > [4] https://www.gabriel.urdhr.fr/img/kitty-thunderbird2.png The above examples prompt the user, so they're making an explicit choice. That's less of an issue. > > Or it's the users responsibility to configure their system to > > view shell files rather than execute them, if they are in the habit of > > clicking exe's attached to emails or otherwise clicking untrusted shell > > scripts. > > Or it is our responsibility to ship with a secure by default configuration? I'm leaning towards shipping kitty-open.desktop under /usr/share/doc/kitty/examples and adding a note to README.Debian about how to install it and the implications. I've not used this particular functionality of Kitty, so I'm not sure how this will change the usual user experience. However, I think this is a safer default and provides more information to the user. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
Bug#1034875: kitty: Should not handle application/x-sh mime type by executing the script
Hi, In the mean time, it's probably a good idea to drop "application/x-sh;application/x-shellscript" from the list of supported mime type to limit the risk. (I assume that even with "text/plain" and a .sh file extension or a shebang, kitty might still decide to execute the script... so the issue is not entirely fixed, but it reduces the number of cases where "kitty +open" is invoked on shell scripts) Indeed, you can use a file with MIME type such as text/ascii or x-scheme-handler/kitty and a .tool file extension and it will be executed through kitty. Affected software include: mail clients (mutt, Thunderbird [3,4]), browsers (Firefox [1,2]), PDF viewers (Okular [5]). [1] https://www.gabriel.urdhr.fr/img/kitty-firefox1.png [2] https://www.gabriel.urdhr.fr/img/kitty-firefox2.png [3] https://www.gabriel.urdhr.fr/img/kitty-thunderbird1.png [4] https://www.gabriel.urdhr.fr/img/kitty-thunderbird2.png [5] https://www.gabriel.urdhr.fr/img/kitty-okular.png And yet having shell scripts opened in the shell is a perfectly reasonable thing to do, for example when browsing shell scripts in your file manager. This kind of things should probably only happen if the file is marked as executable. File and MIME type associations which can trigger arbitrary code execution without user confirmation are very dangerous. They might be be triggered through unexpected ways. The user might be tricked into believing he is opening a "safe" file. These associations should probably not be enabled by default. In this case, mutt should be modified to have a separate view vs open action. It is not only mutt (see above for other examples). Or it's the users responsibility to configure their system to view shell files rather than execute them, if they are in the habit of clicking exe's attached to emails or otherwise clicking untrusted shell scripts. Or it is our responsibility to ship with a secure by default configuration? The user might not be aware that he is opening a shell script either because he has been tricked (using different MIME type and file extension) or because he is not especially skilled in computer/security. Even if he is aware that he is opening a shell script (which might trigger arbitrary code execution and take control of his computer) he might not be aware that "opening" means "executing" in this context. Regards, Gabriel OpenPGP_signature Description: OpenPGP digital signature
Bug#1034875: kitty: Should not handle application/x-sh mime type by executing the script
And yet having shell scripts opened in the shell is a perfectly reasonable thing to do, for example when browsing shell scripts in your file manager. Indeed this feature exists because it was requested by users. It cant be the URL handling applications responsibility to know what the user intended and protect them from themselves. In this case, mutt should be modified to have a separate view vs open action. Or it's the users responsibility to configure their system to view shell files rather than execute them, if they are in the habit of clicking exe's attached to emails or otherwise clicking untrusted shell scripts. Removing or crippling a capability in URL consuming software is not the solution to clicking URLs. On Wed, May 03, 2023 at 02:07:37PM -0400, James McCoy wrote: > Keeping the full text for Kovid's benefit. > > On Wed, Apr 26, 2023 at 02:50:47PM +0200, Raphael Hertzog wrote: > > Package: kitty > > Version: 0.26.5-4 > > Severity: serious > > Tags: security > > X-Debbugs-Cc: Debian Security Team > > > > Hello, > > > > I was reading https://lists.debian.org/20230425190728.ga1471...@subdivi.de > > in mutt and that mail contains 3 shell scripts as attachments > > (application/x-sh). I wanted to have a look at the scripts and thus I > > "opened" those attachments... that open operation has been handled by > > Kitty due its MimeType declaration in > > /usr/share/applications/kitty-open.desktop [1] and the shell script has > > thus been fed to "kitty +open
Bug#1034875: kitty: Should not handle application/x-sh mime type by executing the script
Keeping the full text for Kovid's benefit. On Wed, Apr 26, 2023 at 02:50:47PM +0200, Raphael Hertzog wrote: > Package: kitty > Version: 0.26.5-4 > Severity: serious > Tags: security > X-Debbugs-Cc: Debian Security Team > > Hello, > > I was reading https://lists.debian.org/20230425190728.ga1471...@subdivi.de > in mutt and that mail contains 3 shell scripts as attachments > (application/x-sh). I wanted to have a look at the scripts and thus I > "opened" those attachments... that open operation has been handled by > Kitty due its MimeType declaration in > /usr/share/applications/kitty-open.desktop [1] and the shell script has > thus been fed to "kitty +open
Bug#1034875: kitty: Should not handle application/x-sh mime type by executing the script
Package: kitty Version: 0.26.5-4 Severity: serious Tags: security X-Debbugs-Cc: Debian Security Team Hello, I was reading https://lists.debian.org/20230425190728.ga1471...@subdivi.de in mutt and that mail contains 3 shell scripts as attachments (application/x-sh). I wanted to have a look at the scripts and thus I "opened" those attachments... that open operation has been handled by Kitty due its MimeType declaration in /usr/share/applications/kitty-open.desktop [1] and the shell script has thus been fed to "kitty +open
