NSD Security
This page is to summarize and allow recording ideas related to security and privacy for Network Service Discovery.
Initial list provided by Youenn Fablet, thanks!
1. Local devices may have buggy SSDP/MDNS implementations leading to security issues such as running arbitrary code.
Proposals/Solutions:
- SSDP/MDNS implementation is performed by the user agent and no discovery processes are ever exposed to web pages.
2. Local services knowledge is a good way to fingerprint a user.
The NSD makes it easier to collect user specific information.
To be noted that a web page can already try to do fingerprinting without the NSD based on the local environment.
Proposals/Solutions:
- The current solution is to request user agreement which removes any automatic fingerprinting risk.
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.
Proposals/Solutions:
- Implementations are now required by the spec to do a preliminary CORS check to a.) ensure the service endpoint is actually HTTP (restrict sharing with web pages to HTTP endpoints only which was the original intention also) and b.) ensure that the service endpoint allows cross-origin resource sharing (CORS) with the entry script's origin that called getNetworkServices().
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.
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.).