FYI: Ports 5060 and 5061 to be added to the restricted list

[Adam Rice]

As a workaround for the "Slipstream" NAT bypass attack, we will be blocking HTTP and HTTPS connections to the SIP ports 5060 and 5061. This will mean that connections to servers on those ports will fail.

Impact:

• Connections to servers on those ports, for example http://example.com:5060/ or https://example.com:5061/ will no longer work. This is expected to be rare.
• Tests that spin up a server on an arbitrary port and then expect to be able to connect to it will be slightly more flaky than they are already.

Firefox and Safari are also implementing this mitigation. See https://github.com/whatwg/fetch/pull/1109 for the standard change.

See https://samy.pl/slipstream/ for details of the attack. Briefly, a carefully-crafted HTTP request to port 5060 on an attacker's server can fool some NAT devices into treating it as a SIP packet and setting up port forwarding to an attacker-controlled port number. The attacker's server can then connect back to the client on that port.

[Mike West]

Hey Adam!

This does not feel like an FYI to me. It's a web-facing change that's certainly visible to developers. I'm happy to see that the change is happening in conjunction with other vendors, but it seems reasonable to me to run this through the same intent process that we use for other potentially breaking changes. That ensures that folks are notified of the change, and have a chance to weigh in on aspects you may not have considered.

As it stands, I'll be happy to LGTM an intent, as there's security value to making the change, the breakage risk seems intuitively low, and the value of a TAG review seems equally low given the narrow nature of the change. But nothing about this change seems to me to require bypassing that process.

 

-mike

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAC_ixdzFf1J4BQPpR%2B2XO7VgxnWegrzHQaw3iROYwsQN1eKvWQ%40mail.gmail.com.

[Adam Rice]

I don't think the intent process is well suited for urgent security issues. In fact I was surprised to find there wasn't already an explicit exception.

I have filed an intent to implement and ship at https://groups.google.com/a/chromium.org/g/blink-dev/c/tTGznHWRB9U/m/5h2nMRsoAQAJ.

[Yoav Weiss]

On Tue, Nov 10, 2020 at 7:53 AM Adam Rice <ri...@chromium.org> wrote:

I don't think the intent process is well suited for urgent security issues. In fact I was surprised to find there wasn't already an explicit exception.

I have filed an intent to implement and ship at https://groups.google.com/a/chromium.org/g/blink-dev/c/tTGznHWRB9U/m/5h2nMRsoAQAJ.

I LGTMed, but agree with Mike that this calls for an intent. (while expecting the API owners to be responsive on that front, and pinging them until they are :D)

 

On Tue, 10 Nov 2020 at 04:35, Mike West <mk...@chromium.org> wrote:

Hey Adam!

This does not feel like an FYI to me. It's a web-facing change that's certainly visible to developers. I'm happy to see that the change is happening in conjunction with other vendors, but it seems reasonable to me to run this through the same intent process that we use for other potentially breaking changes. That ensures that folks are notified of the change, and have a chance to weigh in on aspects you may not have considered.

As it stands, I'll be happy to LGTM an intent, as there's security value to making the change, the breakage risk seems intuitively low, and the value of a TAG review seems equally low given the narrow nature of the change. But nothing about this change seems to me to require bypassing that process.

 

-mike

On Thu, Nov 5, 2020 at 3:22 AM Adam Rice <ri...@chromium.org> wrote:

As a workaround for the "Slipstream" NAT bypass attack, we will be blocking HTTP and HTTPS connections to the SIP ports 5060 and 5061. This will mean that connections to servers on those ports will fail.

Impact:

• Connections to servers on those ports, for example http://example.com:5060/ or https://example.com:5061/ will no longer work. This is expected to be rare.
• Tests that spin up a server on an arbitrary port and then expect to be able to connect to it will be slightly more flaky than they are already.

Firefox and Safari are also implementing this mitigation. See https://github.com/whatwg/fetch/pull/1109 for the standard change.

See https://samy.pl/slipstream/ for details of the attack. Briefly, a carefully-crafted HTTP request to port 5060 on an attacker's server can fool some NAT devices into treating it as a SIP packet and setting up port forwarding to an attacker-controlled port number. The attacker's server can then connect back to the client on that port.

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAC_ixdzFf1J4BQPpR%2B2XO7VgxnWegrzHQaw3iROYwsQN1eKvWQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAC_ixdz%2Bkjiu4ewpQ9-M8ucwqPVVF1vhQtk%2B-gZsftnCU-x9Vw%40mail.gmail.com.

[Harald Alvestrand]

Given that this is likely to impact only people who are either:

- trying to hack SIP servers or NAT devices
- running dynamic ports in the 1024-32767 range (see https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml for why this is a Bad Idea)

it seems unlikely that this will have a measurable impact on legitimate usage.

I think there should be some lower limit to where we apply an intent process.
(FWIW, I've landed a related mitigation - https://chromium-review.googlesource.com/c/chromium/src/+/1986070 - without asking. It seemed to be only conforming to established policy.)

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEhX51FHQfSbm0LBrsRmiLLq2tAr87WcVFXR5MTk17_UGA%40mail.gmail.com.

[Anne van Kesteren]

On Tue, Nov 10, 2020 at 8:53 AM 'Harald Alvestrand' via blink-dev
<blin...@chromium.org> wrote:
> (FWIW, I've landed a related mitigation - https://chromium-review.googlesource.com/c/chromium/src/+/1986070 - without asking. It seemed to be only conforming to established policy.)

Why should that not be standardized?

[Harald Alvestrand]

It already is. https://w3c.github.io/webrtc-pc/#dfn-administratively-prohibited

When I make minor changes that I don't think have any effect on legitimate usage, and the change has already been discussed and decided in the standard, I don't think it's good use of time to use the intent process.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADnb78gin8MNEQ21ngn%3DE1wUOFuU%2Bn-c6wpo8Vc8FDeFYcxEig%40mail.gmail.com.

[Anne van Kesteren]

On Tue, Nov 10, 2020 at 10:59 AM Harald Alvestrand <h...@google.com> wrote:
> It already is. https://w3c.github.io/webrtc-pc/#dfn-administratively-prohibited

But that is extremely open-ended. Why not actually call out the port
restrictions? I guess I should file an issue...

[Harald Alvestrand]

Yes, it was written in order to let people do what they have to do for security reasons without having to wait for the standards process to run its course.

(This was not inserted due to the NAT slipstream. It was written due to a previous round of port-abusing attacks. The attack was novel, and required changes that weren't obvious before the attack happened.)

[Yoav Weiss]

https://www.chromium.org/blink/launching-features#TOC-Exempt-features: says "You do not need to use this process if your change does not affect web API behavior to the point that developers need to be aware of it."

I understand that you're arguing that this is the case here, yet the dynamic ports case you mentioned above, while a Bad Idea™, is still something legitimate developers may do. Therefore, prohibiting a specific port is still something developers need to be aware of. (otherwise, you could similarly argue that we can block that entire range without consulting the process)

Regarding standardization and the points Anne made, while we might not be able to wait for standard discussions to settle before mitigating attacks, IMO we should definitely document them, either as normative language when that makes sense, or as part of the non-normative sections when mitigations may vary based on UA opinions. 

[Cody Herzog]

Hello.

Will this have any impact on SIP WebSockets?

I assume not.

Thanks.

[Adam Rice]

If the SIP WebSocket server ran on port 6080 or 6081, then yes. However, RFC7118 says:

   In the absence of DNS SRV resource records or an explicit port, the
   default port for a SIP URI using the "sip" scheme and the "ws"
   transport parameter is 80, and the default port for a SIP URI using
   the "sips" scheme and the "ws" transport parameter is 443.

Since JavaScript cannot read DNS SRV records, I think that this means in practice WebSocket over SIP will be on port 80 or 443, so it won't be affected.

[Cody Herzog]

That makes sense.

Thank very much.