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

Status: RESOLVED FIXED

(Core :: Networking, enhancement, P2)

Description

[Frederik Braun [:freddy]]

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.

Comment 1

[Frederik Braun [:freddy]]

Attachment: Bug 1674735 - add port 5060 to bad port list r=valentin

Comment 2

[Frederik Braun [:freddy]]

Attachment: Bug 1674735 - update wpt to block 5060, 5061

Depends on D95504

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/96087b511fe9
add port 5060 to bad port list r=valentin,necko-reviewers

Comment 4

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/96087b511fe9

Comment 5

[Robo]

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.

Comment 6

[Frederik Braun [:freddy]]

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.

Comment 7

[Frederik Braun [:freddy]]

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

Comment 8

[Ryan VanderMeulen [:RyanVM]]

Do we need this on ESR78?

Comment 9

[Frederik Braun [:freddy]]

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:

Comment 10

[Frederik Braun [:freddy]]

(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 11

[Frederik Braun [:freddy]]

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:

Comment 12

[Ryan VanderMeulen [:RyanVM]]

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.

Comment 13

[Ryan VanderMeulen [:RyanVM]]

Is this test ready to land?

Comment 14

[Frederik Braun [:freddy]]

On ESR? Yes. Should apply cleanly.

Comment 15

[Julien Cristau [:jcristau]]

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

Comment 16

[Frederik Braun [:freddy]]

Oh. Rebased patch coming.

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ebd751c2b104
update wpt to block 5060, 5061 r=jgraham

Comment 18

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/26700 for changes under testing/web-platform/tests

Comment 19

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/ebd751c2b104

Comment 20

[Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 21

[Julien Cristau [:jcristau]]

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

approved for 78.6esr

Comment 22

[Julien Cristau [:jcristau]]

https://hg.mozilla.org/releases/mozilla-esr78/rev/50f9a9029146

Comment 23

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr78/rev/ee74652be00b

Comment 24

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/cc671fea05fa