https://bugs.kde.org/show_bug.cgi?id=379294
--- Comment #6 from Egmont Koblinger <egm...@gmail.com> --- > in that hypothetical scenario with mutt you could put the blame on mutt all > you want for not filtering out this new escape sequence (or supporting it), > it's still a security issue that wouldn't be there without this. If an email client emits the email's contents raw as-is (including control characters, escape sequences) to the terminal, than that is a serious problem that should be reported and fixed as soon as possible. And yes, in that case it's _that_ email client (or other console-based app) to blame! I'm quite confident mutt is not such a client. It's probably the most popular console-based email client across developers, geeks etc. who know what they're doing, and such a bug would almost sure have been discovered by now. Actually, it's one of the very few email clients immune to the recently discovered EFAIL (https://efail.de/) security issue, which makes me trust them to a reasonable degree. Moreover, it uses ncurses for screen rendering, so it _has_ to convert the email's contents into a different model anyway, and if it doesn't filter out the escape characters, then ncurses does it. In order to make mutt send an explicit hyperlink escape sequence to the terminal, triggered my a maliciously crafted email; you'd need to find a yet undiscovered bug in mutt or ncurses, which is probably not much more likely than finding a remote code execution bug. Or making it send an escape sequence to which the terminal emulator responds by injecting keystrokes (yes there are such escape sequences), potentially triggering further actions in mutt. Of course, we're not talking about "mutt", we're talking about "any email client", "any IRC client" etc. > as for the xdg-open thing; say you get xdg-open to launch via an URI handler > with the arguments %20--%20rm%20-f%20--no-preserve-root%20/, How do you get it to do this? Or if you can, what stops this from happening when clicking on a malicious URL in your favorite browser? Why would konsole launch xdg-open with this scheme-less URI as argument if it's potentially harmful? > and get it to > launch gnome-terminal with the passed arguments. Again, how would you do this? Why would xdg-open's parameter become a direct parameter to gnome-terminal (after URI decoding and splitting at spaces)? If that's the case then that's a security problem that can already be exploited at many other places. > entry point could be a > funnily named file displayed by e. g. tab completion or something else > non-obvious, since one of the use example functioning cases is clicking on > files displayed by ls. As per the specs, URIs should be fully qualified ones, beginning with a scheme. "ls" is only able to produce hyperlinks beginning with "file://", and so would be any shell implementing hyperlinks e.g. at tab completion. If I understand you correctly, you've come up with a vaguely outlined scenario of how things could go wrong, assuming that about 3 or 4 other components are all buggy in a way that probably each of them opens up security holes already, even without explicit hyperlink support in the terminal emulator. I really doubt any of these holes actually exist. If they do, they should be fixed. If you're unsure but worried, you could double-check these yourself, and file bugs if required. > (fwiw, konsole already supports clicking on filenames > by tracking the current directory + known mimetypes, without the security > issues.) Could you please elaborate on this? How can I try it out? (I have konsole 17.12.3.) Clicking, ctrl+clicking, right-clicking after an "ls" doesn't do anything for me. How does it know which directory is being listed, how does it know how the listed file's directory relates to the current working directory (especially in case of multiple arguments to ls, or recursive listing)? How does it know the working directory of the running command? The only thing it could do is to poll it, which is quite expensive, and subject to race condition. Oh wait, how does it even know which descendant process outputs the given data, i.e. which descendant process's working directory to check? How does it know what kind of escaping does "ls" do (see its --quoting-style parameter)? How does it recognize and treat filenames containing special characters? How does it know if "ls" was executed over an "ssh", hence its output refers to a remote file? For the explicit hyperlink support there is a specification answering all these. Is there for konsole's approach? Assuming that for start, you'd limit explicit hyperlink support to the "file", "http" and "https" schemes only. In that case I'm absolutely certain that OSC 8 is superior to what konsole does currently, even including security implications. > my point is that security is not binary, and security in depth is good. > basically; everywhere I see this could be useful it is a decrease in > security, providing a new possible part of an exploit chain. My point is that security doesn't mean unreasonable paranoia. And you can't just blindly assume that 3-4 other components all have security issues that aren't important enough to handle them yet, but along with this new feature would open up new holes. -- You are receiving this mail because: You are watching all bug changes.
