Bug#877656: kodi: supports insecure download of non-free addons

[Jonas Smedegaard]

Quoting Felipe Sateler (2017-10-03 23:32:24)
> On Tue, Oct 3, 2017 at 5:49 PM, Jonas Smedegaard <dr at jones.dk> wrote:
> > Package: kodi
> > Version: 2:17.3+dfsg1-2
> > Severity: grave
> 
> This severity feels a bit inflated. After all, you can download and
> run non-free programs using a web browser too!

When you browse into <https://evil.example.com/>, download scarycode.sh 
from there and execute it in a shell, then you are to blame if your foot 
gets blown away.

If instead you open your media center, it automatically updates an addon 
but the http connection gets hijacked and redirected to 
http://evil.example.com/ where scarycode.sh instead gets loaded and 
blows off your foot, then I dare say not you but your media center is to 
blame.


> > Tags: security upstream patch
> > Justification: user security hole

What severity would you use for user security hole?  Or do you disagree 
that using hardcoded http in an _internal_ interface is a user security 
hole?


> > Kodi supports downloading and loading addons at runtime.
> >
> > Official addon feed is served only via http and contain non-free 
> > addons.
> >
> > Allowing to extend the system with non-free addons at runtime by 
> > default is arguably an anti-feature in itself.  Doing so insecurely 
> > poses a risk of malicious code getting into users' home and executed 
> > by Kodi.
> >
> > Attached patch relaxes to make addon feed optional.
> 
> Making plugin feeds optional sounds good though.

Right.

I realize my choice of words might be confusing: feed is optional in 
code with the patch, meaning it won't fail to start if missing.  On the 
packaging level I however intend at first to have kodi _recommend_ the 
feed, so it will be pulled in by default - so until an alternative exist 
it is an "opt-out" not an "opt-in".


> > I intend to move the addons feed configuration file to a separate 
> > package "kodi-repository-kodi" and, at first, ship that package in 
> > main recommended by kodi.
> >
> > Later when an alternate package "kodi-repository-curated" is 
> > available¹, I intend to favor that over kodi-repository-kodi and 
> > move the latter to contrib.
> 
> I don't think moving to contrib makes sense. Either the package fits 
> the requirements for main or it doesn't.
> 
> I don't think this package should go in contrib, as it doesn't *need* 
> any software not available in main. So it should not be moved there.

Whoops, that final part was not meant to be sent: I agree package being 
insecure is not a reason to move it to contrib (I got distracted by that 
other political aspect which we are not in consensus about).


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private