Bug 379294

Wouldn't this be a security issue?

I don't think so. See my detailed response in the comments section of the gist page.

it won't directly lead to code execution, but can be used for phishing, or it can be used in a chain of other "not quite direct security holes" (e. g. an application that runs commands it receives as arguments getting launched by xdg-open).

a concrete example; user receives malicious mail in mutt with a link to phishing.com disguised as a link to mybank.com.

I'd say wontfix, but not up to me.

Some security implications were discussed in the comments section of the gist page. In my opinion, so far the only valid concern was raised in https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda#gistcomment-2404153.

As for your hypothetical example with mutt: Without mutt supporting explicit hyperlinks, there's nothing that would change just by the terminal emulator adding support. If mutt adds support too, then you _might_ claim it becomes mutt's responsibility to filter these out or warn the user, just as much as you _might_ claim that it's the responsibility of any GUI or web-based e-mail client capable of handling HTML e-mail. I'm wondering: is it really theirs? And then what about regular webpages having such malicious URLs (maybe displayed inside a terminal emulator, in a text based browser), aren't these a problem?

As a rule of thumb, I believe that as long as we add something to the terminal emulator which is already there in browsers, there's no (new) hole opened up.

I don't get your phishing or xdg-open references either, you'd need to provide more concrete examples.

If you have any worries about the feature (irrelevant to Konsole in particular), I'd be glad if you raised them for discussion on the gist page.

my point is that security is not binary, and security in depth is good.


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.


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/, and get it to launch gnome-terminal with the passed arguments. 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. (fwiw, konsole already supports clicking on filenames by tracking the current directory + known mimetypes, without the security issues.)

but again; not a clear cut place to put the blame, but wouldn't be possible without this.


basically; everywhere I see this could be useful it is a decrease in security, providing a new possible part of an exploit chain.

> 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.

again, I was just coming up with hypothetical scenarios based on the use cases of the proposed feature (having "magic" links in mutt seems kind of reasonable, as does clickable files starting applications to view them). neomutt is probably a better hypothetical target, they're a bit less conservative in what kind of features they implement.

and I'm fairly certain konsole never implemented the escape sequences for injecting keystrokes in the first place either (and was not susceptible to the window title escape sequence trick either).

about the clickable filenames it's a bit off topic for this bug, but you need to turn in on in the settings. and how konsole tracks the current directory depends on OS and shell (if it supports OCS7), but that feature is much older, but earlier it was just used to display the current directory in the window/tab title.


> And you can't just blindly assume that 3-4 other components all have security issues

I think that's where you and I disagree. you could make the same argument against sandboxing and many other defense in depth strategies.


but misunderstand me correctly; I'm not violently opposed to this, I just don't believe the security/usefulness tradeoff is good here.

(In reply to Martin Sandsmark from comment #7)

> and I'm fairly certain konsole never implemented the escape sequences for
> injecting keystrokes in the first place either

Not arbitrary keystrokes, but certain ones. Try e.g.

    echo -ne '\e[>c'

> about the clickable filenames it's a bit off topic for this bug, but you
> need to turn in on in the settings. and how konsole tracks the current
> directory depends on OS and shell (if it supports OCS7), but that feature is
> much older, but earlier it was just used to display the current directory in
> the window/tab title.

Thanks, now I've found it. As expected, it only works for a simple "ls". As soon as I do an "ls some-other-directory", it no longer works, or even worse, can mistake a file for its counterpart of the same name from another directory. I don't even dare to try whitespaces and other weird characters in the filename.

> > And you can't just blindly assume that 3-4 other components all have security issues
> 
> I think that's where you and I disagree. you could make the same argument
> against sandboxing and many other defense in depth strategies.

Sandboxing is not just for security, sure its part of their stories, but other parts are about avoiding the hassle with conflicting libraries etc. And as for security, there it's an entire OS with plenty of features and plenty of potentially broken places, that is, gazillions of possible entry points for security bugs. A pretty wide system diagram, if you wish, whereas for the OSC 8 feature it's a simple stack with a very small number of components.

And I'd like to emphasize again that the feature was modeled after web browsers, so if there's any security hole in its implementation, it's probably already there even without the terminal emulator. We didn't invent anything brand new, just applied something already seen on the web into terminal emulators.

> but misunderstand me correctly; I'm not violently opposed to this, I just
> don't believe the security/usefulness tradeoff is good here.

Usefulness if of course another question. I myself often use it for local filenames, as printed by "ls". And as opposed to konsole where it works _sometimes_, for me it works _always_.

I am still not convinced at all about security issues, especially if konsole decides to limit support to a few well-known schemes.

And don't get me wrong, I'm not completely against security either, see e.g. another feature request for gnome-terminal at https://bugzilla.gnome.org/show_bug.cgi?id=795774 which, although could be a convenient one, I don't support due to its security implications. I just don't see the security problems in the hyperlink story.

Anyway, I guess we need to agree that we disagree.

*** This bug has been confirmed by popular vote. ***

Proof of Concept Implementation: https://invent.kde.org/utilities/konsole/-/merge_requests/138

(In reply to Egmont Koblinger from comment #6)
> 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!

An obvious example of a tool that sends arbitrary data to the terminal without filtering escape sequences is cat. cat'ting an untrusted file shouldn't be a security vulnerability. Others include head and tee. Many programs such as find or ls filter escape sequences by default when sending output directly to a terminal, but not if they are piped into head or tee. There are so many ways untrusted data can end up printed to a terminal that I don't think it's practical to prevent them all.

If outputting arbitrary data to the terminal causes security problems, IMO it's the terminals that should be fixed. Not the least because (safe) escape sequences can be useful for formatting even in untrusted text files. As far as I  understand, most modern terminal emulators don't have really dangerous escape sequences; the sequences the terminal may respond with as keystrokes generally don't correspond to actual keyboard input.

That said, even if untrusted text can display unfiltered hyperlinks, it's not more dangerous than a website as long as dangerous URLs are not automatically opened.

> That said, even if untrusted text can display unfiltered hyperlinks, it's not more dangerous than a website as long as dangerous URLs are not automatically opened.

The whole point of the feature is to decouple what people see and what URL is opened.

I think the fundamental difference between Egmont and me is where security issues should be handled. I believe Konsole should be robust against even very dumb issues in all other parts of the system (from applications showing URLs, via applications that handle file:// or http{,s}:// URLs, to users).

For everything else I agree with Egmont, Konsole (nor other terminal emulators) shouldn't try to implement hacks to work around bugs in applications. But when it comes to security I'm a bit more conservative, and default to assume that everything else is broken. Including users not checking that the URL they thought they clicked is the one they ended up with in the browser.

And Konsole has also been a bit conservative wrt. security vs. features in the past, hence why it has avoided some issues in the past (https://www.hdm.io/writing/termulation.txt is probably the most famous, hitting everything from xterm to gnome-terminal). And also why e. g. Konsole has an annoying popup when you try to paste something with weird characters (it has stopped warning about emojis at least): https://georg.so/pub/cat.html


Aaaanywho, Tomaz' implementation has been merged, so closing this as done.

Created attachment 161355 [details]
attachment-251980-0.html

We already have hyperlink support.


On Sun, Sep 3, 2023 at 6:06 AM Matt Whitlock <bugzilla_noreply@kde.org>
wrote:

> https://bugs.kde.org/show_bug.cgi?id=379294
>
> Matt Whitlock <kde@mattwhitlock.name> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>                  CC|                            |kde@mattwhitlock.name
>
> --
> You are receiving this mail because:
> You are the assignee for the bug.