[vlc-devel] [PATCH 9/9] lua: http: Announce the web interface over mdns

[Pierre Ynard]

> Could you elaborate?
> 
> If you feel that we need to make some changes before we can advertise
> the web interface I'm fine with the idea, but then I'd like to discuss
> an actual plan.

I invite you to check the recent changelog for the web interface, and open
trac tickets for that component:

https://trac.videolan.org/vlc/query?status=assigned&status=new&status=reopened&component=Interface%3A+HTTP+server&col=id&col=summary&col=component&col=status&col=type&col=priority&col=milestone&order=priority

- HTTPS links to third-party web assets (https://git.videolan.org/?p=vlc.git;a=commitdiff;h=49cddd79e05a7280914b4124c9dba3cabb7a8d80)
- no-referrer policy (https://git.videolan.org/?p=vlc.git;a=commitdiff;h=875b573f1779c3428ea746aca870552945b87274)
- asking user before using remote QR code API (https://git.videolan.org/?p=vlc.git;a=commitdiff;h=e891b5bb1fd946a4c2430270f7422932c35e8bb8)
- HTML integrity attributes on third-party resources (not used now)
- checking Origin header against CSRF attacks (https://trac.videolan.org/vlc/ticket/19626)
- actually disabling access without password (https://mailman.videolan.org/pipermail/vlc-devel/2020-September/137085.html)
- TLS support (https://trac.videolan.org/vlc/ticket/19807)

These are all security and privacy weaknesses with real threat models
behind them. But these were/are just the low-hanging fruit that I picked
up or noticed; and at the same time the tip of the iceberg as their real
extent is much more complicated to fix.

- Even if their integrity is checked, remote third-party resources still
give away the location of the web interface: either through traffic
analysis, or by passing its URL plain in a query string parameter and
back as a QR code image (https://trac.videolan.org/vlc/ticket/25020).
Hopefully this can be fixed in the next version of the web interface
front end.

- Even if basic CSRF is deterred, there are still more advanced attacks
such as DNS rebinding (https://trac.videolan.org/vlc/ticket/19627).

- Even if we properly enforce password protection, the first thing
people do about it is to set a trivial password. We have no proper
password management: no policies and mechanisms to reject weak passwords
(too short, too simple, vulnerable to dictionary attacks), to deter
brute-force attacks, nor to enforce changing old or compromised
passwords. No support either for delegating authentication - for
example against system credentials - assuming these could be trusted
to be secure enough for remote access, and VLC could be trusted not
to compromise them. Here we join a usual issue of striking a balance
between usability and security, which the whole industry has faced, and
many times got wrong themselves.

- Even if TLS is supported, it requires valid certificates. So we join
the usual issue of distributing TLS certificates in consumer products,
which the whole industry has faced, and many times got wrong themselves.

Furthermore, there is no security model in the web interface: once you
gain basic access, anything goes.

- There is no folder-based access control. By default web servers serve
only the contents of /var/www, and even user directory modules serve
only ~/public_html (emphasis on "public"). If you set up network shared
folders on Windows, you have to enable each folder on an opt-in basis,
and if you try sharing a whole drive it will strongly discourage you
from doing so. In VLC's web interface, you can freely browse the whole
file system, by default and with no means to restrict it. An attacker
can open and stream away to themselves any file on the system with read
access, and can overwrite any file with write access.

- There is no model for safe, unsafe or privileged features: basic
access opens access to the full feature set of VLC, including obvious
abuse vectors such as the stream output, network inputs to inject
content controlled by the attacker, or making requests from VLC's host
to partake in DDoS attacks or attack their LAN, etc... There is even
plain access to the VLM shell! Raw features are exposed through the
web interface based on desirability and technical feasibility, with
hardly any discretion about security. There is no concept of admin
login or reinforced security to access more sensible features. We have
such a mechanism for configuration variables: they can be tagged with
`change_safe()` to make them available as input options from untrusted
sources such as playlist files; but nothing such for the web interface.

- There is no access control or session management model. HTTP Basic
authentication is the bottom of the barrel: the password is sent in
cleartext in every request, and the credentials never expire, making
it easier to abuse with CSRF. We used to have ACLs based on allowed
subnets, but they were removed in favor of the single password -
admittedly they had their drawbacks. However maybe we could have session
expiration, or prompting to re-enter the password when trying to access
sensitive features. There is also nothing to log, warn about and review
suspect connections from unknown devices; and an access control model
such as pop-ups asking "Do you want to allow this new device to control
VLC?" might actually be a rather desirable UX.

Finally, it is one thing to be vulnerable to information leaks, traffic
analysis, compromises and crafted attacks. But sending advertisements
using any kind of standardized mechanism is subscribing to the botnet.
Do you want to subscribe to the botnet? One intended target would be
VLC remote applications for smartphones; well, do you want to send away
advertisements to all these foreign-made smartphones carefreely running
all those third-party apps? There aren't only nice, featured-oriented
people in the botnet.

-- 
Pierre Ynard
"Une âme dans un corps, c'est comme un dessin sur une feuille de papier."