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 <t...@security.debian.org> > > > > 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 <script>" which actually executed the > > script. > > I thought there was a distinction between "view" and "execute", and > tools like mutt would prefer viewing. Maybe that's legacy mimetools > support I'm thinking of, though, and not something handled by desktop > files. Either that, or it's another precedence thing (like gimp opening > pdf files) and defining a default application for the mime type would > work around the issue. > > > 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). > > > > 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) > > I would agree that having kitty-open registered by default for such > filetypes isn't optimal. I could ship kitty-open.desktop as an example, > instead of by default, but that still wouldn't inform people about the > implications of installing it. > > > Thank you for your work on kitty! > > > > [1] Extract of /usr/share/applications/kitty-open.desktop: > > Comment=Open URLs with kitty > > Exec=kitty +open %U > > MimeType=image/*;application/x-sh;application/x-shellscript;inode/directory;text/*;x-scheme-handler/kitty; > > -- > James > GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB -- _____________________________________ Dr. Kovid Goyal https://www.kovidgoyal.net https://calibre-ebook.com _____________________________________
