RE: [discovery-api] Mitigating real-world device compromise

I agree with Dom that app:// URLs are difficult to implement and probably  not sufficient as well.

UPnP ContentDirectory services will advertise raw URLs for media content.
Filtering cannot be restricted to the origin of the service (media content URLs may not have the same origin as the UPnP service).
Additional app URLs would need to be created dynamically.

App URLs also do not solve the problem described in [1].
If an attacker can interact with the service through an app URL, it may be able to partially identify it.
Once identified, the attacker can restrict the possible IP address, port and path to a much smaller set of values.

If one wants to obfuscate IP addresses, mdns is already available in most platforms.
That works best if done on the device side (no IP address leakage at all).
It may also be done by the browser itself for disclosed IP-URL-based services (with potential IP address leakage when exchanging messages).

For fine-grained service isolation, SOP seems interesting.
Note though that path is currently not sufficient to isolate all services.
WMP for instance uses the query string to differentiate between ContentDirectory and ConnectionManager services.
If a web app gets access to the ContentDirectory service, it also gets access to the ConnectionManager service (which is probably ok as they are part of the same UPnP device).

> >> Maybe this is something we should bring to the WebAppSec WG to get
> >> their input?

+1

> > I'm wondering if browsers should not operate in their own local VPN
> > that would isolate them from the local network setup; they would then
> > be in a position to mediate any access to the "real" local network
> > (e.g. via NSD), and impose by default much stronger access policies.
> 
> While I think some of these have the potential of fixing the problem perhaps
> they also go too far in restricting access completely. I'm not sure how that
> plays with existing local network web content (e.g.
> Intranet systems).

The "local VPN" is an interesting idea.
I do not think that a call to the NSD API should trigger access rules modification though.

The only solution for [1] may be to restrict GET requests triggered through HTML elements.
This is not a small change.
For devices that have unstable hostnames/origins, one could restrict GET requests triggered through HTML elements to origins owned by the device itself.
Following on the "local VPN" idea, that may be the default rule for devices that run discoverable services.
This may not be disruptive to intranet services that generally do not run such services and have statically assigned host names.

With all of this, it may be feasible to define browser specific rules for legacy devices, such as "enable access to WMP and MediaTomb services".
This would translate into setting some specific SOP rules such as:
- Enable GET access to http://mylocalservice:XX/my_content_media_path/ from any origin
- Enable XHR access to http://mylocalservice:YY/my_content_directory_service/ from any origin
- Otherwise, GET access to device origins
Future devices would define their own rules using extended CORS/SOP headers or manifests.

If that can work, the NSD API would solely concentrate on the discovery of services, making its UI issues tractable.

Regards,
 Youenn

> > > [1]
> > > http://shadow-file.blogspot.com.au/2013/10/complete-persistent-

> compr
> > > omise-of.html

Received on Monday, 4 November 2013 11:10:36 UTC