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

[Rémi Denis-Courmont]

Le keskiviikkona 9. syyskuuta 2020, 15.01.06 EEST Hugo Beauzée-Luyssen a écrit 
:
> > 1) Port scanning might be viable on a large campus to find some always-on
> > VLC. Hopefully a strong enough password, and a decent network security
> > policy prevents breaking in. Advertising is telling everything on the
> > local network that you're there now. Any cheap stupid hacked IOT gadget
> > or CPE can pick it up and MITM, as can somebody else on a public WiFi.
> > 
> > There is definitely some overlap with port scanning, but it looks like
> > orders of magnitude worse exposure. It's also more visible and thus more
> > prone to hostile PR.
> > 
> > 
> > 2a) The advertising in itself actually adds a MITM risk, as the remote
> > applications have no means to distinguish the legitimate announces from
> > attacker's. Currently at least the user has to verify the IP address. So
> > it's not just adding exposure to the existing insecure interface, it's
> > actually making the sethings even more insecure.
> 
> I don't understand the concept of MITM when announcing an identify.

OK so a more correct term would be spoofing, with MITM being one of the 
potential bad consequences.

In the current system. the user has to input the correct IP address (and port 
number) of the server on the more app. With advertisement, any attacker can 
supply their own IP and/or port number, and there are no ways for the user to 
see the attack.

Normal, you work around that by verifying the server identity after 
connecting, so the spoofing can only achieve a DoS, not a full compromise. 
That's totally missing.

> I get
> that an attacker could try and impersonate a running VLC but then you end
> up with 2 VLCs with a different IP, and that should instruct anyone to
> check why there are 2, and which one to connect to, if not giving up before
> finding out why there are duplicated records.

No. The most likely reason for two advertisement is that there is a caching 
error or VLC was restarted, etc. That's not something that I would worry 
about, or expect users to worry about. Conversely, if it really is caused by 
an attack, then there's a problem.

And there's also the obvious trivial case that the advertisements are disabled 
on the client. Then there won't even be duplicates.

> > 2b) It's not even clear that the proposed API (patch 1) can sustain the
> > hypothetical secure control interface. In fact, it looks very much like it
> > can't, as there are no ways to tie the announce to any kind of identity.
> 
> I'm not sure to understand that point, you have the service name, type,
> additional TXTs, and IP/hostname. That's as far as MDNS goes (AFAIK)

And how do you supply that to the API proposed in patch 1?

> > 3) There is no sunset strategy for advertising the non-secure interface.
> > If we cannot even agree to remove an obscure user-hostile feature that
> > literally never worked like VLM schedules, how are we ever going to
> > remove this user friendliness feature if it gets merged?
> 
> Discussing until reaching consensus,

I don't think you will never achieve consensus to merge this before security 
is implemented. I don't think you would ever achieve consensus to keep or 
remove it if it were merged either.

> I suppose, but why would we need a sunset strategy for something that isn't
> merged

Because that's when you'd typically want to have a sunset strategy if 
applicable?

> when the issue appears to be an already merged feature.

I don't think that the issue of hostile or compromised host on the subnet 
finding vulnerable HTTPd without prohibitively slow port scans is already 
merged, nor is the issue of spoofing an advertised instance.

> I feels to me like this is something the users should be warned about, and
> could advertise at their own risks, but IMO the risk is rather low in most
> environment

Full read/write access to filesystem is not "rather low" IMO, more like rather 
extremely high. Full write typically means full system compromise on a desktop 
or server OS.

Not to mention recording webcam, microphone, and the virtual desktop, which 
are kinda moot at this point.

-- 
雷米‧德尼-库尔蒙
http://www.remlab.net/