Re: GUPnP and Zones

[Jussi Kukkonen <jussi kukkonen intel com>]

On 22 April 2013 14:53, Mark Ryan <mark d ryan linux intel com> wrote:
> Hi All,
>
> I've been thinking about security a bit lately, from the point of view of
> the client and not the server.
>
> Obviously, we don't want to run a DMS or a DMR on any Wifi Network we
> connect to.  However, it occurs to me that we don't want to run the control
> points on public networks either as doing so might introduce an attack
> vector, i.e., someone could create a fake server that forces the clients to
> download and parse dodgy XML files. They could also send dubious notify
> messages to the port opened up by the control point to receive
> notifications.  I could be being over paranoid here, but it seems to me that
> it's not safe to run any UPnP client on a public network.  It's also a waste
> of resources to do so.

I've been thinking about this a bit now. I agree on everything you
said above but there is another aspect: The expectations seem quite
different for different apps.

* For a standalone upnp media player the act of starting the app is
already the user signaling that "yes, I would like to see all the
media on this network I'm currently connected to".
* For a media player (that happens to support upnp as well) that might
no longer be the case: the user might not even know upnp is supported.
In this case it might make sense to show the server names (or "Show
media servers on this network") in the UI, but only access them in any
way if the user makes the decision of clicking.
* On the other hand a caching middleware component probably shouldn't
access a mediaserver unless it is told to do that by an app or it
somehow knows that we are in a "safe" network.

For the first two cases adding another layer of UI (outside the apps
control) seems wrong, and I wouldn't be surprised if app developers
would be annoyed about that. I don't have specific ideas about how to
solve this but I think the apps should have fairly strong control over
this.

Jussi