Security/Reviews/TCPSocket: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Created page with "{{SecReviewInfo |SecReview name=Expose a client TCP socket/UDP datagram API to web applications }} {{SecReview}} {{SecReviewActionStatus |SecReview action item status=None }}")
 
No edit summary
Line 1: Line 1:
{{SecReviewInfo
{{SecReviewInfo
|SecReview name=Expose a client TCP socket/UDP datagram API to web applications
|SecReview name=Expose a client TCP socket/UDP datagram API to web applications
|SecReview target=<bugzilla>
{
"id":"750563,733573 745283"
}
</bugzilla>
* https://groups.google.com/d/topic/mozilla.dev.webapps/Asm37KDoVB4/discussion
}}
{{SecReview
|SecReview feature goal=Goals
Expose  Socket API so that Web Apps can connect to services requiring such  access (e.g. SMTP Web App). Eventually this is planned to be a  privileged socket API for all platforms, but this review is based on the  b2g implementation which is critical for version 1.
Note  that for Apps which just need cross-domain http, there is a seperate  permission for relaxing  XHR restrictions (bug 692677). Only apps which  truly need raw socket access should use this API.
TCP
Currently  this API is client-only, and allow connection to a specific host/domain  on a specified port. Optionally, SSL can be requested. (STARTTLS is  also a planned feature). Connections can be any host/port.
UDP
Use  case is to resolve MX records for domain, to aid in autoconfiguration,  but there are probably other use cases in the future. NOT For v1.
*TCP Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=733573
*UDP bug: https://bugzilla.mozilla.org/show_bug.cgi?id=745283
** No UDP for the first patch
===Background Questions===
*  Could any security restrictions be applied to mitigate security risk? 
** Could require apps to at declare what hosts/ports they will connect to. If they want to "*" they will need to justify this.
**  Increase the level of paranoia for private IP addresses  (maybe for Trusted apps we ALWAYS prompt for conenctions to  private Ip  ranges, eg 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16..)
*** https://bugzilla.mozilla.org/show_bug.cgi?id=354493
**  Block loopback altogether? There is no way for an app to listen  on loopback at the moment, so maybe prevent connections to rule out  connecting to debug ports etc? Or maybe this is unneccesary (hopefully  b2g wont have any ports open by default?)
**  For trusted apps (as opposed to certified) ensure that only foreground  apps can make connections - is this possible ("foreground" is a gaia  concept, this is a DOM/gecko API - we would need a way to expose that to  the API or something)
*** Probably hard to impliment but not a lot of protection
* How will certificate errors be handled?
**  Currently, certificate errors mean failed connection. For b2g, a Gaia  UI and API to expose certificate information is needed (unless this is  build into b2g?). There is a very valid use case to be able to accept  self-signed/invalid certs though for email clients, since this is  common.
*** Have an option saying "i want to handle errors" or have a way on the phone to install certs
*** need to decide whether app handles errors or some system component
* What is the permission model for this:
a) implicit permissions, all hosts
b) implicit permissions, hosts specified in manifest (or * in manifest for all hosts)
c) explicit permission per host (ie user is prompted per host, option to remember)
*  What happens if the permission is revoked? (nothing I think - do we  want to change this so that changing the permission closes the socket? I  would kind of expect that)
**  Certified model: specify hosts/ports in the manifest, permissions  granted implicitly and not able to be revoked (unless device is in  developer mode)
**  Trusted model: specify hosts/ports in the manifest, permissions granted  implicity. user can modify permissions? User prompted on first run?
*  (out of scope but important)  How will credentials be stored (assuming  that apps making connections  will need credentials to make secure  connections)
|SecReview threats considered=
|SecReview threat brainstorming=** Malicious website uses API to connect to internal resource
** Increased port scanning capability
** Data exfiltration - can envision this being a target for malware
** Connection to local device
** Increased attack surface area, API could be vulnerable to command injection, memory issues, who knows what
}}
}}
{{SecReview}}
{{SecReviewActionStatus
{{SecReviewActionStatus
|SecReview action item status=None
|SecReview action item status=In Progress
|SecReview action items=* Investigate restriction options - maybe via CSP. (nsiContentPolicy check)
* Investigate whether to handle cert errors in app or in a b2g system component
}}
}}

Revision as of 16:05, 24 May 2012

Please use "Edit with form" above to edit this page.

Item Reviewed

Expose a client TCP socket/UDP datagram API to web applications
Target 
   
     Full Query
ID Summary Priority Status
733573 Expose a client TCP socket API to web applications P1 RESOLVED
750563 [Security Review] Expose a client TCP socket P2 RESOLVED

2 Total; 0 Open (0%); 2 Resolved (100%); 0 Verified (0%);

{{#set:SecReview name=Expose a client TCP socket/UDP datagram API to web applications

|SecReview target=

Full Query
ID Summary Priority Status
733573 Expose a client TCP socket API to web applications P1 RESOLVED
750563 [Security Review] Expose a client TCP socket P2 RESOLVED

2 Total; 0 Open (0%); 2 Resolved (100%); 0 Verified (0%);

}}

Introduce the Feature

Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)

Goals Expose Socket API so that Web Apps can connect to services requiring such access (e.g. SMTP Web App). Eventually this is planned to be a privileged socket API for all platforms, but this review is based on the b2g implementation which is critical for version 1. Note that for Apps which just need cross-domain http, there is a seperate permission for relaxing XHR restrictions (bug 692677). Only apps which truly need raw socket access should use this API. TCP Currently this API is client-only, and allow connection to a specific host/domain on a specified port. Optionally, SSL can be requested. (STARTTLS is also a planned feature). Connections can be any host/port. UDP Use case is to resolve MX records for domain, to aid in autoconfiguration, but there are probably other use cases in the future. NOT For v1.

Background Questions

  • Could any security restrictions be applied to mitigate security risk?
    • Could require apps to at declare what hosts/ports they will connect to. If they want to "*" they will need to justify this.
    • Increase the level of paranoia for private IP addresses (maybe for Trusted apps we ALWAYS prompt for conenctions to private Ip ranges, eg 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16..)
    • Block loopback altogether? There is no way for an app to listen on loopback at the moment, so maybe prevent connections to rule out connecting to debug ports etc? Or maybe this is unneccesary (hopefully b2g wont have any ports open by default?)
    • For trusted apps (as opposed to certified) ensure that only foreground apps can make connections - is this possible ("foreground" is a gaia concept, this is a DOM/gecko API - we would need a way to expose that to the API or something)
      • Probably hard to impliment but not a lot of protection
  • How will certificate errors be handled?
    • Currently, certificate errors mean failed connection. For b2g, a Gaia UI and API to expose certificate information is needed (unless this is build into b2g?). There is a very valid use case to be able to accept self-signed/invalid certs though for email clients, since this is common.
      • Have an option saying "i want to handle errors" or have a way on the phone to install certs
      • need to decide whether app handles errors or some system component
  • What is the permission model for this:

a) implicit permissions, all hosts b) implicit permissions, hosts specified in manifest (or * in manifest for all hosts) c) explicit permission per host (ie user is prompted per host, option to remember)

  • What happens if the permission is revoked? (nothing I think - do we want to change this so that changing the permission closes the socket? I would kind of expect that)
    • Certified model: specify hosts/ports in the manifest, permissions granted implicitly and not able to be revoked (unless device is in developer mode)
    • Trusted model: specify hosts/ports in the manifest, permissions granted implicity. user can modify permissions? User prompted on first run?
  • (out of scope but important) How will credentials be stored (assuming that apps making connections will need credentials to make secure connections)

What solutions/approaches were considered other than the proposed solution?

`

Why was this solution chosen?

`

Any security threats already considered in the design and why?

Threat Brainstorming

    • Malicious website uses API to connect to internal resource
    • Increased port scanning capability
    • Data exfiltration - can envision this being a target for malware
    • Connection to local device
    • Increased attack surface area, API could be vulnerable to command injection, memory issues, who knows what

{{#set: SecReview feature goal=Goals Expose Socket API so that Web Apps can connect to services requiring such access (e.g. SMTP Web App). Eventually this is planned to be a privileged socket API for all platforms, but this review is based on the b2g implementation which is critical for version 1. Note that for Apps which just need cross-domain http, there is a seperate permission for relaxing XHR restrictions (bug 692677). Only apps which truly need raw socket access should use this API. TCP Currently this API is client-only, and allow connection to a specific host/domain on a specified port. Optionally, SSL can be requested. (STARTTLS is also a planned feature). Connections can be any host/port. UDP Use case is to resolve MX records for domain, to aid in autoconfiguration, but there are probably other use cases in the future. NOT For v1.

Background Questions

  • Could any security restrictions be applied to mitigate security risk?
    • Could require apps to at declare what hosts/ports they will connect to. If they want to "*" they will need to justify this.
    • Increase the level of paranoia for private IP addresses (maybe for Trusted apps we ALWAYS prompt for conenctions to private Ip ranges, eg 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16..)
    • Block loopback altogether? There is no way for an app to listen on loopback at the moment, so maybe prevent connections to rule out connecting to debug ports etc? Or maybe this is unneccesary (hopefully b2g wont have any ports open by default?)
    • For trusted apps (as opposed to certified) ensure that only foreground apps can make connections - is this possible ("foreground" is a gaia concept, this is a DOM/gecko API - we would need a way to expose that to the API or something)
      • Probably hard to impliment but not a lot of protection
  • How will certificate errors be handled?
    • Currently, certificate errors mean failed connection. For b2g, a Gaia UI and API to expose certificate information is needed (unless this is build into b2g?). There is a very valid use case to be able to accept self-signed/invalid certs though for email clients, since this is common.
      • Have an option saying "i want to handle errors" or have a way on the phone to install certs
      • need to decide whether app handles errors or some system component
  • What is the permission model for this:

a) implicit permissions, all hosts b) implicit permissions, hosts specified in manifest (or * in manifest for all hosts) c) explicit permission per host (ie user is prompted per host, option to remember)

  • What happens if the permission is revoked? (nothing I think - do we want to change this so that changing the permission closes the socket? I would kind of expect that)
    • Certified model: specify hosts/ports in the manifest, permissions granted implicitly and not able to be revoked (unless device is in developer mode)
    • Trusted model: specify hosts/ports in the manifest, permissions granted implicity. user can modify permissions? User prompted on first run?
  • (out of scope but important) How will credentials be stored (assuming that apps making connections will need credentials to make secure connections)

|SecReview alt solutions=' |SecReview solution chosen=' |SecReview threats considered= |SecReview threat brainstorming=** Malicious website uses API to connect to internal resource

    • Increased port scanning capability
    • Data exfiltration - can envision this being a target for malware
    • Connection to local device
    • Increased attack surface area, API could be vulnerable to command injection, memory issues, who knows what

}}

Action Items

Action Item Status In Progress
Release Target `
Action Items
* Investigate restriction options - maybe via CSP. (nsiContentPolicy check)
  • Investigate whether to handle cert errors in app or in a b2g system component

{{#set:|SecReview action item status=In Progress

|Feature version=` |SecReview action items=* Investigate restriction options - maybe via CSP. (nsiContentPolicy check)

  • Investigate whether to handle cert errors in app or in a b2g system component

}}

Retrieved from "https://wiki.mozilla.org/index.php?title=Security/Reviews/TCPSocket&oldid=434141"