Security/Reviews/TCPSocket

From MozillaWiki
Jump to: navigation, search
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%);

The given value "
   
     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
  • Property "SecReview feature goal" (as page type) with input value "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)" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
    • Property "SecReview threat brainstorming" (as page type) with input value "** 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" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.

Action Items

Action Item Status In Progress
Release Target `
Action Items
Who bug Action By When Completed date

[NEW] new [DONE] Done [MISSED] Miss

pauljt 763930 Investigate restriction options - maybe via CSP. (nsiContentPolicy check) TBD [NEW] new
pauljt 763931 Investigate whether to handle cert errors in app or in a b2g system component TBD [NEW] new
Full Query
ID Summary Priority Status
763930 SecReview: Expose TCP Socket - Investigate restriction options - maybe via CSP. (nsiContentPolicy check) -- NEW
763931 SecReview: Expose TCP Socket - Investigate whether to handle cert errors in app or in a b2g system component -- RESOLVED

2 Total; 1 Open (50%); 1 Resolved (50%); 0 Verified (0%);

The given value "

Who bug Action By When Completed date [NEW] new [DONE] Done [MISSED] Miss


pauljt 763930 Investigate restriction options - maybe via CSP. (nsiContentPolicy check) TBD [NEW] new


pauljt 763931 Investigate whether to handle cert errors in app or in a b2g system component TBD [NEW] new


Full Query
ID Summary Priority Status
763930 SecReview: Expose TCP Socket - Investigate restriction options - maybe via CSP. (nsiContentPolicy check) -- NEW
763931 SecReview: Expose TCP Socket - Investigate whether to handle cert errors in app or in a b2g system component -- RESOLVED

2 Total; 1 Open (50%); 1 Resolved (50%); 0 Verified (0%);

" contains strip markers and therefore it cannot be parsed sufficiently.