Closed Bug 750563 Opened 13 years ago Closed 13 years ago

[Security Review] Expose a client TCP socket

Categories

(mozilla.org :: Security Assurance: Review Request, task, P2)

Product:
mozilla.org
Component:
Security Assurance: Review Request
Type:
task

Tracking

(blocking-kilimanjaro:+, blocking-basecamp:+)

Status:
RESOLVED FIXED
Project Flags:
blocking-kilimanjaro +
blocking-basecamp +

People

(Reporter: curtisk, Assigned: pauljt)

References

(Depends on 1 open bug)

Details

(Whiteboard: [LOE:S] [Score:56:Medium])

SecReview tracking bug Actions regarding the review of the dependent bug should be tracked here.
Summary: SecReview: Expose a client TCP socket API to web applications → [Security Review] Expose a client TCP socket API to web applications
Priority: -- → P1
Combining UDp and TCP socket reviews since it is the same person.
Blocks: 745283
Summary: [Security Review] Expose a client TCP socket API to web applications → [Security Review] Expose a client TCP socket/UDP datagram API to web applications
tem to be reiviewed: Expose a client TCP socket/UDP datagram API to web applications Link to calendar entry: https://mail.mozilla.com/home/ckoenig@mozilla.com/Security%20Review.html?view=month&action=view&invId=110473-110472&pstat=AC&exInvId=110473-179809&useInstance=1&instStartTime=1337803200000&instDuration=3600000 SecReview Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=750563 Security Lead: Paul Theriault Required Reading List: * https://groups.google.com/d/topic/mozilla.dev.webapps/Asm37KDoVB4/discussion * (If possible prefill this area for copying to the notes section of the review) Introduce Feature (5-10 minutes) [can be answered ahead of time to save meeting time] - Goal of Feature, what is trying to be achieved (problem solved, use cases, etc) Web Apps need socket connectivity to connect to services such as IMAP. - 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 (30-40 minutes) ** Malicious website uses API t o 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 * Conclusions / Action Items (10-20 minutes)
THis is only a review of TCP sockets, renamed as such.
Summary: [Security Review] Expose a client TCP socket/UDP datagram API to web applications → [Security Review] Expose a client TCP socket
do we need a second bug for UDP part? Can you update the dates in the tags please as well?
(In reply to Curtis Koenig [:curtisk] from comment #5) > do we need a second bug for UDP part? I don't think the UDP API is going to happen at this point. The motivating B2G/Gaia need would be so that we could issue DNS queries from JS, but we can already do that with TCP, it will just take a little longer. (And we may end up just reusing Thunderbird's XHR-accessible lookup service.)
blocking-basecamp: --- → +
How are we doing here?
I am going to unblock on this because this clutters the list of engineering bugs to work on. We should never the less obviously finish this work asap, and block on any mandatory follow-up items that come out of it. Please renom if you disagree with this rationale.
blocking-basecamp: + → ---
Per conversation with :gal putting the flags back, we need to make sure this work is done before ship.
blocking-basecamp: --- → +
blocking-kilimanjaro: --- → +
Whiteboard: [pending secreview][start mm/dd/yyyy][target mm/dd/yyyy] → [LOE:S]
In terms of a status update, the initial review is complete here, pending a permission model for this API, and the two follow-up bugs (how to apply CSP and how to handle SSL). Like most new Web APIs the security review is blocked on the application of the permissions, however I have been on leave for two weeks so not sure of the current status.
:pauljt - do we need to change this to resolved-fixed?
oh, i said I would followup- followup is permission model is still under development and my priority it permissions testing atm.
Priority: P1 → P2
Risk/Priority Ranking Exercise https://wiki.mozilla.org/Security/RiskRatings Priority: 4 (P2) - Mozilla Initiative Operational: 0 - N/A User: 3 - Major Privacy: 3 - Major Engineering: 3 - Major Reputational: 5 - Blocker Priority Score: 56
Whiteboard: [LOE:S] → [LOE:S] [Score:56:Medium]
Permission is implemented: http://mxr.mozilla.org/mozilla-central/source/dom/network/src/TCPSocket.js#303 Testing confirm permission is required to access the functionality.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.