KDE Connect's security?

[Albert Vaca]

Bug reports created:

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

Now we should fix them :P


On Tue, Jun 24, 2014 at 8:19 PM, Aleix Pol <aleixpol at kde.org> wrote:
> 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
>