RE: NSD API security

Hi Frederick,

It may be actually worth storing a list of identified security issues.
This is somehow similar to a list of requirements that the NSD specification should deal with.
And we should obviously avoid losing any of them.

Below an initial list capturing the ones I am aware of.
That could serve as a cross-check for future versions of the security section of the NSD spec.
Maybe a wiki page would be better suited so that it can be further corrected and improved.

Regards,
	Youenn

Issues related to service discovery:
1.	Local devices may have buggy SSDP/MDNS implementations leading to security issues such as running arbitrary code
Probably not issue for NSD as browser/trusted code is doing the discovery protocol interactions and will behave nicely.

2.	Local services knowledge is a good way to fingerprint a user
The NSD makes it easier to collect user specific information.
Current solution is to request user agreement, which reduces automatic fingerprinting risk.
To be noted that a web page can already try to do fingerprinting without the NSD based on the local environment.

Issues related to the discovery of services not accessible through XHR
1.	GET requests
A web app is restricted to issuing GET requests to resources (images, CSS.) that may exist or not.
Depending on the particular service implementation, this may hypothetically lead to various attacks: DoS? buffer overflow?
Probably not a high security risk anyhow.
The NSD does not open any new door (an attacker can already try to load resources from IP addresses usually used by ADSL routers for instance) but this makes an attacker's life easier.

Issues related to the use of XHR on discovered services
1.	User fingerprinting based on data gathered from a service
Fingerprinting is made easier if a web app can collect content from a particular service (playlists, images.)
No solution envisioned here except user agreement requested at discovery time.

2.	DoS attacks to local services
Probably not the biggest security issue - this is already partially feasible without NSD.
No solution envisioned to circumvent this within the NSD.
XHR browser implementations may envision countermeasures?

3.	Arbitrary network requests sent to hack a device
Web apps may only issue HTTP or WebSocket correctly formatted messages.

4.	HTTP requests with invalid content sent to hack a device
A web app may send corrupted messages (wrong SOAP messages, missing values, badly-formatted values, specific HTTP headers.), leading to potential DoS or worse (run arbitrary code?). 

No solution envisioned to circumvent this within the NSD.
CORS/NSD solution solves this by only allowing access to service implementations that state they can cope with those issues.
Message generation/validation by trusted code removes that risk but requires the knowledge of the particular service type.

5.	HTTP requests with valid content sent to hack a device
These requests are valid according a particular service type but, with well-set values, lead to security issues.
This is the kind of issues faced by routers with some IGD implementations.

CORS/NSD solution solves this by only allowing access to service implementations that state they can cope with those issues.
Message generation/validation by trusted code removes that risk but requires the knowledge of the particular service type.

Issues related to the blacklist/whitelist mechanism
1.	Take over one service of a device to get access to another functionality in the same device
This is the case of a router that implements IGD and A/V UPnP service (Is there any other existing hybrid case?)
Hacking through A/V service may lead to control LAN management capacities. 

Service-type black-list solution is not always sufficient.
Such a hybrid device will be blacklisted if IGD service is enabled.
If IGD service is disabled, the device will not be blacklisted.
The browser may also take router-specific countermeasures (disallow CORS XHR for any service whose address resolves to the router IP address).

2.	Take over one service of a device to take over another device
If there is a weak service served by a local server that can be taken over (leading to running arbitrary code on the local server),  
the server may then try to contact a black-listed device such as a router to open ports...
Whitelist/blacklist may not solve this except if taking into account specific device implementation identifiers (model number.).


> -----Original Message-----
> From: Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com]
> Sent: jeudi 3 octobre 2013 03:29
> To: FABLET Youenn
> Cc: Frederick.Hirsch@nokia.com; bh526r@att.com; richt@opera.com;
> dom@w3.org; giuseppep@opera.com; public-device-apis@w3.org; public-
> web-and-tv@w3.org
> Subject: Re: NSD API security
> 
> Youenn
> 
> Much thanks for bringing this conversation to DAP with the pointers to the
> various implementation discussions - this is very useful, so thank you.
> 
> It seems we have general consensus on CORS support required in new
> devices but not so much clarity on the tradeoff of enabling legacy devices vs
> the security issues, and also have some thinking to do regarding Zeroconf.
> 
> Even so I'm not quite sure how we can address some of the security
> concerns, such as the "router and music service combined device" risk. If
> such a combined device has an implementation flaw enabling an attack, then
> the music side could be used to take control of the router with severe
> consequences, but apart from disallowing discovery and use I'm not quite
> sure which countermeasures Network Service Discovery can offer (regardless
> of CORS).
> 
> The fundamental flaw is that one device has two purposes  allowing flaws
> from one to affect the other, yet this is also why it is sold and valued - the
> convenience, cost reduction, lower hardware footprint, easier management
> etc are also benefits.
> 
> We should address the case in the Security Considerations (we should cover
> the concerns which have been raised repeatedly), but am not quite sure what
> we should say - do not use dual purpose devices, or MUST NOT allow
> discovery of such a device (or not support CORS or be whitelisted, effectively
> keeping it out of scope) or highlight that this is a risk related to data transfer
> once discovered and that there should be limitations related to buffer
> overflow attempts etc
> 
> We should discuss and add more to the security considerations, if only to
> highlight various concerns.
> 
> Frederick Hirsch
> Nokia
> 
> 
> 
> On Oct 1, 2013, at 3:09 AM, ext FABLET Youenn wrote:
> 
> > Defining a good blacklist/whitelist may not be an easy task.
> > Such a list may evolve over time, there is no guarantee that different
> implementations of the same service type be all safe, a single device may
> implement both a safe type and an unsafe type...
> >
> > Legacy devices can already be accessed by packaged apps and browser
> extensions without whitelisting.
> > Existing services (AV content storage, renderers, printers...) may already be
> useful to existing packaged apps (music players, image managers...).
> > What is missing is the discovery part. This may trigger early NSD API market
> adoption.
> > Enabled features would be translated to web pages once CORS become
> implemented in devices, using exactly the same code base.
> >
> > Early adopters of the NSD API for web apps may resort on browser
> extensions to access discovered legacy devices, be they HTTP or not.
> > Some experiments (https://github.com/youennf/nsdExperiments) showed
> the feasibility of "bridge" extensions that would either validate-then-send or
> generate-then-send requests on behalf of a web app (more study needed on
> security aspects though).
> > The web app code adaptation needed to access both CORS-enabled and
> legacy devices is for instance fairly low.
> > Resorting on extensions is probably not that appealing to web developers,
> but this may still be a viable transition approach.
> >
> > A single version of the NSD API should make possible these different
> approaches.
> > Starting from the current specification, that would probably mean
> removing the whitelisting mechanism.
> > Probably also keeping user permission to cover fingerprinting issues.
> >
> > Regards,
> > 	Youenn
> >
> >> -----Original Message-----
> >> From: HU, BIN [mailto:bh526r@att.com]
> >> Sent: vendredi 27 septembre 2013 00:28
> >> To: Rich Tibbett; Dominique Hazael-Massieux
> >> Cc: Giuseppe Pascale; FABLET Youenn; public-device-apis@w3.org;
> >> public- web-and-tv
> >> Subject: RE: NSD API security
> >>
> >> At AT&T side, we support Rich and Dom's proposal of supporting both
> >> CORS as the primary mode and whitelisting for legacy devices.
> >>
> >> While CORS approach will be good for implementers to start with from
> >> now on, current legacy devices on market cannot be ignored. If we
> >> don't support legacy devices, I am not sure if market eventually will
> >> adopt NSD with CORS only approach, or the market will be fragmented.
> >>
> >> Thus CORS + whitelisting approach is more reasonable to keep the
> >> market support.
> >>
> >> Thanks
> >> Bin
> >>
> >> -----Original Message-----
> >> From: Rich Tibbett [mailto:richt@opera.com]
> >> Sent: Friday, September 20, 2013 3:44 AM
> >> To: Dominique Hazael-Massieux
> >> Cc: Giuseppe Pascale; FABLET Youenn; public-device-apis@w3.org;
> >> public- web-and-tv
> >> Subject: Re: NSD API security
> >>
> >> On Fri, Sep 20, 2013 at 6:18 PM, Dominique Hazael-Massieux
> >> <dom@w3.org> wrote:
> >>> Le vendredi 20 septembre 2013 à 17:28 +1000, Rich Tibbett a écrit :
> >>>> So there are a number of directions we could take this in:
> >>>>
> >>>> 1. Focus the specification around a CORS-only solution. CORS is an
> >>>> accepted mechanism to allow cross-origin communication on the web
> >> and
> >>>> could work well in the local network environment also. The problem
> >>>> with adopting a CORS-only approach is we have zero devices
> >>>> currently ready to step in to this brave new world with us. A
> >>>> specification that allows you to connect with precisely zero
> >>>> network services will not be useful.
> >>>
> >>> I think that no matter what, the spec should support a CORS-based
> >>> approach.
> >>
> >> A CORS approach only? As I said, there are no services I'm aware of
> >> that would work with that today so we would also have to see if
> >> device vendors are interested in releasing CORS-based devices and
> >> services. I know we have a few device vendors on this list so it
> >> would be good to hear their opinions at this point.
> >>
> >>>
> >>>> 2. Support whitelisting of specific local network services in the
> >>>> user agent, at the user's request to enable communication with
> >>>> those services. Even if we went with a CORS-only approach (see (1.)
> >>>> above), this could be a practical fallback to support
> >>>> existing/legacy network services. This would provide
> >>>> non-CORS-enabled services with the same privileges as CORS-enabled
> >>>> services from the user agent without the service itself needing to
> >>>> support CORS implicitly (as also proposed in the current NSD API
> specification).
> >>>
> >>> I support the idea (at least in theory - it would remain to be seen
> >>> whether any user agent would feel confident to support such a
> >>> whitelist); but given that this is an exception mechanism, I'm not
> >>> even sure it needs to be specified -  since the user agent is
> >>> ultimately responsible for managing the same origin policy,
> >>> user-specified exceptions to that policy (which such a whitelist
> >>> would
> >>> be) seem beyond what we need to define for interoperability. Or did
> >>> you have in mind some specific aspects that would need to be spec-d
> here?
> >>
> >> It may warrant a note in the spec to say that a user agent MAY
> >> whitelist non- CORS-enabled network services and that if it does so
> >> it MUST pass through XHR/WebSocket messages to the network service
> >> endpoints as if they were CORS enabled.
> >>
> >> Other than that, I don't anticipate any other issues with interoperability.
> >>
> >>>
> >>> Dom
> >>>
> >

Received on Friday, 4 October 2013 13:42:06 UTC