[konsole] [Bug 379294] Implement OSC 8 hyperlink support

[Egmont Koblinger]

https://bugs.kde.org/show_bug.cgi?id=379294

--- Comment #6 from Egmont Koblinger <egmont at 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 the assignee for the bug.