Create Task
Maniphest T10766

KDE Connect Plugin Security
Open, NormalPublic
Actions

Description

I'm concerned about the behaviour of how plugins send data to other devices (PC or mobile).

In using KDE Connect to send files and URLs from my phone to a PC, the default behaviour is to accept all and open URLs immediately, with no alternative configuration. This means that KDE Connect "share" can be used to send either a malicious URL or files to a computer without a user knowing about. The URL would be instantly opened and the receiving device could then be infected with further malware or compromised in other ways.

I tried to change this behaviour by adding a notification function into the "share" plugin... but then ended up with errors on my build. [Apparently include "KNotification" doesn't work for the "share" plugin]. However, in thinking about this, shouldn't we have a unified kdeconnect notification sub-system, which allows for any plugin to create a notification in the KDE Connect system tray?

This notification sub-system could also then be a way of ensuring default "sane" security behaviours from plugins. For instance, that plugins first create a notification with some interactive "button" before something is done with the data that is sent. An example would be: I share a URL to a device, a notification pops up with a dismiss button and an "open URL" button. The same would apply to Files, and the Clipboard.

At the moment, it seems each plugin will require its own notification code, which would result in additional work, a lack of code reuse, but most importantly, a major security flaw that could see KDE Connect used to distribute malicious code to other devices.

**I'm very new to Qt coding and don't understand enough about it to do this. I'm willing to learn though and contribute as best I can.

ewentzel created this task.Apr 6 2019, 8:21 AM
ewentzel triaged this task as Normal priority.
nicolasfella added a subscriber: nicolasfella.Apr 6 2019, 1:08 PM

The current behaviour is anything but a "major security flaw". I consider a security issue 'major' when it allows remote code execution without needing other security issues.

KDE Connect's functionality is only active for devices that haven been explicitly paired (and thus are considered trusted). When talking about Linux security the threat model is usually based on the assumption that all software running is coming from the distribution and thus can be considered trusted. Whether that assumption is valid is worth discussing, but elsewhere. Furthermore, opening a URL isn't a major security risk by itself. While it's true that it can be used to trigger existing security flaws this does not make it a "major issue" as per above definition.

That being said, I wouln't oppose to having the behavior you propose as an option.

WRT notifications:
There is some simple form of abstraction for sending notifications (Daemon::instance()->sendSimpleNotification()). The same can be achieved via KNotification::event(). However, both don't expose the complete API KNotifications offers.
I don't see any value in creating another abstraction over KNotifications (which itself is an abstraction over various notification systems. Your issue with KNotifications can probably be solved by linking against KF5::Notifications in plugins/share/CMakeLists.txt