RE: [sysapps/raw socket api]: New version to be reviewed at Madrid F2F-meeting

On 05/04/2013 16:07, Nilsson, Claes1 wrote:
> 
> I guess that this would be possible from a logical point of view.
> However, the current Web Sockets API is available to web pages
> running in the normal browser context, while the SysApps Raw Socket
> API is only available to web applications running in the secure
> SysApps runtime. There are apparently different security implications
> on opening up an API for UDP and TCP sockets compared to an API for
> Web Sockets. So aligning Web Sockets into the same specification as
> UDP and TCP sockets might be tricky from a security point of view.
> Could John and other SysApps security experts comment on this?
> 

I'm not the best person to comment on the importance of alignment of the APIs, but I have thought a bit about the different security implications.  I'm sure I'm not the only one, nor the best qualified to do so, but...

The risk of misuse of a TCP / UDP raw socket API is higher.  These APIs can be used for network scanning and potentially to use the browser to launch attacks against other networked devices.  A poorly implemented app using this API would also be a proxy for launching attacks by an external party.  I can imagine this being a particular concern for anyone in a corporate network, as this API could be used to attack otherwise-firewalled resources, but is also a threat to anyone with a home network containing vulnerable devices (i.e., everyone).  

This issue is already a concern with XHR [1] but it is still constrained by the same origin policy.  Such restrictions cannot be sensibly implemented for the use cases that Claes is working on, as these require apps to be able to discover local resources.  Web Sockets don't have these problems, because the protocol and APIs were designed to take into consideration the web origin model, and the protocol will fail if data from other protocols is used with it [2].  With Web Sockets you're saying "I trust this website to communicate with any web socket server that trusts this origin". With XHR it's "I trust this website to communicate with any HTTP server either of the same origin or that has explicitly allowed it through CORS", but with Raw Sockets you're saying "I trust this website to communicate with *any* accessible endpoint". 

I think more time needs to be spent thinking about how to mitigate some of the threats that a malicious app with access to raw sockets has, even for certified or privileged-level apps.  It could be relatively harmless to align the APIs, or it could be frustrating for developers and result in more privileged apps being developed than there should be.  It is also possible that additional API-level measures need to exist to force safer use of this API, but I'm not sure (at the moment) what these might be.  I haven't looked at the API in enough detail, but principles from [3] ought to apply.  

I look forward to discussing this at the meeting.

Best wishes,

John

[1] http://media.blackhat.com/bh-us-12/Briefings/Purviance/BH_US_12_Purviance_Blended_Threats_WP.pdf

[2] http://tools.ietf.org/html/rfc6455#section-1.6 
[3] Glenn Wurster and P. C. van Oorschot. 2008. "The developer is the enemy". In Proceedings of NSPW '08 -  http://www.scs.carleton.ca/~paulv/papers/nspw08gw.pdf

Received on Monday, 8 April 2013 08:07:46 UTC