Closed Bug 1674735 Opened 11 months ago Closed 11 months ago

block port 5060 for outgoing requests (potentially mitigating NAT slipstreaming)

Categories

(Core :: Networking, enhancement, P2)

enhancement

Tracking

()

RESOLVED FIXED
84 Branch
Tracking Status
firefox-esr78 --- fixed
firefox84 --- fixed

People

(Reporter: freddy, Assigned: freddy)

References

()

Details

(Whiteboard: [necko-triaged], [wptsync upstream])

Attachments

(2 files)

NAT slipstreaming works by tricking "smart" firewalls into parsing non-SIP packets as SIP. This is achieved through some clever hacks, which involve massaging an HTTP request to port 5060 to truncate a certain offset to make a the second, fragmented TCP packet look like SIP.

As a weak mitigating factor, we'll try blocking port 5060 for HTTP requests.
Valentin notes that this blocking can be reversed with a pref update, if things go horribly wrong.

Severity: -- → S3
Priority: -- → P2
Whiteboard: [necko-triaged]

Depends on D95504

Pushed by fbraun@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/96087b511fe9
add port 5060 to bad port list r=valentin,necko-reviewers
Status: ASSIGNED → RESOLVED
Closed: 11 months ago
Resolution: --- → FIXED
Target Milestone: --- → 84 Branch

I think this fix will violate RFC 2616. As written there: The default port is TCP 80 [19], but other ports can be used.
After the change suggested all HTTP services working on non-default port will be unaccessible.
The actual problem is in NAT ALG and should be fixed there. Moreover this fix does not prevent all attacks. There are ALGs that does not check for port number but just check packet content for SIP REGISTER command. They will be still vulnerable.
This fix just "brakes internet" and tries to fix other protocol's vulnerabilities.

First of all, I agree that this change does not fix the complete problem. The original bug description does mention that we are breaking the attack now in the short term, while we are investigating other avenues to fix this long & mid-term.

Secondly, RFC 2616 has been replaced by the RFC 7230 family of RFCs in 2014. These RFCs define how HTTP is implemented, not how a web browser is using HTTP. Outgoing HTTP requests for the purpose of a web browser are standardized in https://fetch.spec.whatwg.org/ which has a list of blocked ports for a very long while. This change is merely updating that list of disallowed ports. The standard has been fixed and other browsers are implementing this block as well.

The list of disallowed ports stems back from rather old attacks where nefarious websites could cause a browser to send semi-conformant SMTP or IRC commands through an HTTP POST request. In light of old and new attacks, we won't ever go back to a browser that will allow arbitrary outgoing ports for HTTP requests.

(I had to edit the comment a couple of times. Apologies.)

Do we need this on ESR78?

Flags: needinfo?(fbraun)

Comment on attachment 9185120 [details]
Bug 1674735 - add port 5060 to bad port list r=valentin

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: blocking a non-HTTP port for HTTP traffic.
  • User impact if declined: less protection
  • Fix Landed on Version:
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Might be risky if enterprises run stuff on very odd ports in their intranet. We don't have telemetry for this. Users can override with a pref. We can also override the blocking with a remote pref, but I honestly don't know if these overrides would be valid for ESR or if we'd remove the protection on all branches. And this bug here is a public issue )
  • String or UUID changes made by this patch:
Flags: needinfo?(fbraun)
Attachment #9185120 - Flags: approval-mozilla-esr78?
Attachment #9185414 - Flags: approval-mozilla-esr78?

(In reply to Ryan VanderMeulen [:RyanVM] from comment #8)

Do we need this on ESR78?

To answer your question: I'm really not sure. The risk discussion in my approval request above tries to weigh this in more detail.

Comment on attachment 9185120 [details]
Bug 1674735 - add port 5060 to bad port list r=valentin

Beta/Release Uplift Approval Request

  • User impact if declined: less protection
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): The port shouldn't be used for HTTP(s) and seldomly is. Users who really need this can override themselves. If there's significant breakage, we can override globally with remote settings
  • String changes made/needed:
Attachment #9185120 - Flags: approval-mozilla-beta?
Attachment #9185414 - Flags: approval-mozilla-beta?

Comment on attachment 9185120 [details]
Bug 1674735 - add port 5060 to bad port list r=valentin

This landed on 84 prior to the uplift to Beta.

Attachment #9185120 - Flags: approval-mozilla-beta?
Attachment #9185414 - Flags: approval-mozilla-beta?
Flags: qe-verify+
QA Whiteboard: [qa-triaged]

Is this test ready to land?

Flags: needinfo?(fbraun)

On ESR? Yes. Should apply cleanly.

Flags: needinfo?(fbraun)

I think Ryan was referring to the second patch here which hasn't landed anywhere yet.

Flags: needinfo?(fbraun)
Attachment #9185414 - Attachment description: Bug 1674735 - update wpt for blocking port 5060,5061 → Bug 1674735 - update wpt to block 5060, 5061

Oh. Rebased patch coming.

Flags: needinfo?(fbraun)
Pushed by fbraun@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ebd751c2b104
update wpt to block 5060, 5061 r=jgraham
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/26700 for changes under testing/web-platform/tests
Whiteboard: [necko-triaged] → [necko-triaged], [wptsync upstream]
Upstream PR merged by moz-wptsync-bot

Comment on attachment 9185120 [details]
Bug 1674735 - add port 5060 to bad port list r=valentin

approved for 78.6esr

Attachment #9185120 - Flags: approval-mozilla-esr78? → approval-mozilla-esr78+
Attachment #9185414 - Flags: approval-mozilla-esr78? → approval-mozilla-esr78+
You need to log in before you can comment on or make changes to this bug.