Bug#855225: kodi: CVE-2017-5982: Unrestricted file download

[Antoine Beaupre]

affects 85225 xbmc
package xbmc
found 85225 2:11.0~git20120510.82388d5-1
thanks

I can confirm this affects both jessie-backports and wheezy. I've been
able to access random files on my Kodi install using:

http://localhost:8080/image/image%3A%2F%2F%2e%2e%252f%2e%2e%252f%2e%2e%252f%2e%2e%252fetc%252fpasswd

Just add more %2e%2e%252f in there if that's not deep enough for you. :)

In wheezy, it's even worse - there's a /vfs/ layer that gives you plain
access to any given path, as bam discovered. But you don't even need any
"special://" protocol, this just works:

http://localhost:8080/vfs/etc/passwd

Given that XBMC 11 (wheezy) and 16 (jessie-backports) are vulnerable, I
would be very surprised if XBMC 13 had any reasonable protections in
place.

As I explained in this post on debian-lts, I'm really unsure how to fix
this issue:

https://lists.debian.org/87zif33oxf.fsf@curie.anarc.at

Should we consider this part of the design that there's basically an
open file manager in the Kodi web browser? That may sound ludicrous, but
that's the way this thing is built right now. There's *some* password
protection as well, although the password is empty by default and is
therefore disabled. A possible workaround would be to force
authentication, even if there are no passwords set. This would require
commenting out this line:

  m_needcredentials = !password.IsEmpty();

in CWebServer::SetCredentials (WebServer.cpp). That way attackers would
be presented with an authentication dialog at least. There's a default
username and password, but at this point we may somehow shift the blame
to the user...

The alternative here is to start enforcing path restrictions on the
requested files in the webserver. This is a difficult operation because,
right now, files can be specified with arbitrary paths, including
relative paths with `../` or absolute paths, and there aren't clear
boundaries to where Kodi "can look": Kodi is designed to take over a
media station and serve contents from all sorts of sources...

So if we change the webserver, we also need to change the callers, and
that could prove more difficult...

A.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20170426/96230056/attachment.sig>