Re: NSD API security

+1

Rich: what about adding this in the spec, in an annex dedicated to security
aspects?


On Fri, Oct 4, 2013 at 3:41 PM, FABLET Youenn <Youenn.Fablet@crf.canon.fr>wrote:

> 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
> > >>>
> > >
>
>