Hi Antoine,
Thanks for the detailed analysis! 2017-04-26 19:05 GMT+02:00 Antoine Beaupre <anar...@orangeseeds.org>: > 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....@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... I have forwarded this info to upstream bug tracker but I have no high hopes in getting the issue solved. I plan blogging about Kodi 17.1 being in both Stretch and Zesty and mention this issue as a reason for people to not trust any installation too much. Cheers, Balint
