KDE Connect's security?

Aleix Pol aleixpol at kde.org
Tue Jun 24 18:19:48 UTC 2014


On Tue, Jun 24, 2014 at 7:48 PM, Albert Vaca <albertvaka at gmail.com> wrote:

> Hello Raphael,
>
> First of all thanks for your message and your contribution to KDE Connect.
>
> On Sun, Jun 22, 2014 at 4:22 PM, Raphael Kubo da Costa
> <rakuco at freebsd.org> wrote:
> > Hi, Albert,
> >
> > I apologize for not sending this directly to the mailing list, but since
> > this has security questions I've opted to first mail you privately
> > first. Please let me know if you'd rather I sent this to the list.
>
> I think it's not a problem to use the mailing list (CCd) to talk about
> this topic.
>
> > I've recently started playing with KDE Connect and finally managed to
> > get it to work on FreeBSD today.
>
> I'm happy that we can have KDE Connect running on FreeBSD systems! Thanks
> again.
>
> > This made me wonder about the amount of thought given to securing KDE
> > Connect so far: I saw a post in your blog about securing the
> > communication between the desktop daemon and the Android device asking
> > for input from security people (and also the comments there), and while
> > trying to fix KDE Connect on FreeBSD I've noticed the kded module opens
> > TCP and UDP sockets binding to all interfaces (so in theory if one's
> > machine is connected directly to the internet anyone could fake a
> > UDP/TCP Android packet). Additionally, any UDP packet not in the right
> > format causes the daemon to exit, which can possibly be used to cause a
> > DoS in kdeconnectd (I didn't check what happens to the TCP packets).
>
> KDE Connect is intended to be used in small networks but, yes,
> potentially we could be receiving faked packets. I don't think this is
> a issue, as the same thing can be said of any application that listens
> to a network port. Since the content of the packets is encrypted, you
> still could not impersonate a trusted (paired) device. You could,
> however, send pairing petitions and spam the user with pairing
> notifications. We could solve this just by adding a "don't show more
> notifications from this device" checkbox to the notification, so I
> don't think it's a big problem.
>
> Apart from that, we should not crash when receiving a malformed
> packet, and that's something we have to fix as soon as possible.
>
> > Given all this, I'd basically like to know if there's been any follow up
> > to those comments about KDE Connect's security design in your blog, and
> > also if those UDP/TCP topics I mentioned above have been considered.
>
> I would prefer somebody with a good background in security to work on
> the issues that came up in the comments of that post, so from my part
> no further investigation has been made. Help in form of discussion, as
> you did, is appreciated as well :)
>
> > Thanks!
>
> Cheers,
> Albert
>

Hi,
First of all, Raphael thanks for bringing this subject, I think it's
important to take it into account.

I don't think we need somebody with a thorough  security mindset, the
problems Raphael pointed out to are real and we can already take action on
them. Maybe we can open bug reports about them so that they don't get lost?

Aleix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20140624/100c61cd/attachment.html>


More information about the KDEConnect mailing list