https://bugs.kde.org/show_bug.cgi?id=501256
Bug ID: 501256
Summary: LSP "Outlput" log treats the LSP server stderr
messages like HTML
Classification: Applications
Product: kate
Version: 24.12.1
Platform: Other
OS: Other
Status: REPORTED
Severity: minor
Priority: NOR
Component: application
Assignee: kwrite-bugs-n...@kde.org
Reporter: ni...@thykier.net
Target Milestone: ---
SUMMARY
When there is a LSP server active, kate has a `Output` tab in the bottom where
you can see logs from the LSP server. This is very nice for debugging the
integration with the LSP server. Unfortunately, the messages from the LSP
server is blindly treated as HTML rather than text. Which means that if the
server messages contain "<" then the log is effectively truncated.
Note: Before filing, I considered whether this should be considered a security
bug. I concluded, it was not. My thought process being the following.
Most LSP servers are started directly by the editor itself and therefore runs
exactly in the same user context as the editor itself. From a security PoV,
they are considered extensions of the editor itself. These have nothing to gain
from a complicated HTML injection attack, since they already have the same
access as the editor itself. For this to be a security bug, the LSP server
would have to be run in a different user context or machine. However, the LSP
specs do not support that use-case, so I have no reason to believe anyone would
use it with kate this way. Notably, the LSP specs already expect the LSP server
to open files in the project directly as necessary behind the editor's back as
long as the editor has not "reserved" it via a `didOpen` notification. This
implies the server is basically run as the same user on the same host in
practice (even in the rare case when the tcp or ws is used for connecting
rather than stdio).
In summary, HTML injection would be a massively complicated way of deploying a
malicious payload that the LSP server could just deploy directly, since it
would gain no new privileges from attacking the client. Since they do not stand
to gain new privileges by using the HTML injection, I believe this is just a
regular bug.
STEPS TO REPRODUCE
1. Activate a LSP server that uses plain`<` in its stderr output in kate. In
my case, it triggered from an error message/crash (concretely a Python
TypeError about the `<` operator not being supported between the two objects
being compared). However, you can also just have it emit HTML to stderr (like
"<i>foo</i>" and see that kate renders the text with formatting and does not
show the HTML tags.
2. Observe that the output log does not show the full text from the LSP server
as it was emitted.
OBSERVED RESULT
The logs were truncated and hide important details for me to debug my LSP
server.
EXPECTED RESULT
That the stderr messages from the server was provided as-is, so it was easier
to debug.
SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Debian Trixie (testing) - using the distribution version for
everything (QT, plasma, and kate, etc.)
KDE Plasma Version: 6.3 (Debian)
KDE Frameworks Version: 6.11.0 (Debian)
Qt Version: 6.7.2 (Debian)
--
You are receiving this mail because:
You are watching all bug changes.
