Subject: [rtcweb] Security issue: initial consent

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 27 Oct 2011 22:37:07 +0000

Howdy,
per the request made by the Chairs for threads on the security daft, I'm starting this one on the topic of initial media-stream consent.  This is related to section 4.2 and in particular 4.2.3 of draft-ietf-rtcweb-security.

With regards to initial consent, earlier proposals to use receipt of RTP from the peer as the consent have failed due to it being easy for a malicious JS site to generate a few RTP packets to accomplish it.  Earlier proposals to send some limited RTP and use receipt of RTCP Receiver Reports have failed because the entropy of RTCP RR's is too low, and thus malicious JS can spoof them too easily; there's also the problem that some legacy devices don't do RTCP. 

IF the above is true, then ISTM the only solution choices are one of the following:
1) Require ICE be used for all connections on the WebRTC Browser, and either ICE or ICE-Lite on the peer.
2) Require either ICE as above _or_ DTLS-SRTP be used for all RTP connection consent, since DTLS-SRTP handshake is sufficient consent.  In other words, if the Browser's peer uses DTLS-SRTP but not ICE, the Browser can use that as initial consent and continue.  If the Browser's peer does ICE, that provides initial consent.

Are there any others??

SDES-SRTP can't be used instead of DTLS-SRTP for such consent, because the JS will know the SDES key. 

I don't believe we need to worry about consent for purely data-stream connections, assuming we pick either SCTP/UDP, SCTP/DTLS/UDP, or TCP/UDP; because there's a handshake of sufficient entropy.  But I could be wrong about that.

I also believe there's one issue regarding consent which has not been documented: ICE-based or DTLS-based resource attacks.  If a malicious JS can trigger STUN-ICE, TURN-allocate, or DTLS-handshake messages to be sent to any destination by feeding the Browser malicious ROAP, the packet rates of those themselves can create a DDoS attack.  I think this needs to be documented so that Browsers throttle the number of such messages they generate.  ICE, for example, can mimic RTP rates during initial connectivity checks; so a malicious JS can simply cause ICE to restart often.

-hadriel

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 27 Oct 2011 15:39:44 -0700

> I don't believe we need to worry about consent for purely data-stream connections, assuming we pick either SCTP/UDP, SCTP/DTLS/UDP, or TCP/UDP; because there's a handshake of sufficient entropy.  B…

Still thinking about this, but...

Can you clarify what TCP/UDP means? Is it TCP over UDP?

-Ekr

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 28 Oct 2011 00:41:27 +0200

> Can you clarify what TCP/UDP means? Is it TCP over UDP?

Yes.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 27 Oct 2011 15:58:46 -0700

>> Can you clarify what TCP/UDP means? Is it TCP over UDP?

In that case, it's not clear that there is enough entropy. The TCP ISN has
(at most 32 bits) and since ISN ACK forgery is not exactly a priority
for ordinary
stacks, it's not clear that they generate the ISN securely.

-Ekr

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 27 Oct 2011 23:39:21 +0000

> stacks, it's not clear that they generate the ISN securely.

Right but we haven't defined what "TCP over UDP" means.  :)

The "TCP" is in the Browser, so we can improve things.  We could, for example, decide that the JS cannot learn the ephemeral source port number of the TCP-layer from the Browser, and that it be chosen randomly every time from the full 16-bit range (as opposed to the small ephemeral range used by most OS's), giving another 16-bits of entropy.  And of course we'd specify that the ISN be chosen securely.  Heck, we could even mandate using a new TCP header option to be reflected by the other side, similar to the TCP Timestamp option, but put a random number in it.

-hadriel

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 28 Oct 2011 00:42:07 +0100

> 1) Require ICE be used for all connections on the WebRTC Browser, and either ICE or ICE-Lite on the peer.

This works.

> 2) Require either ICE as above _or_ DTLS-SRTP be used for all RTP connection consent, since DTLS-SRTP handshake is sufficient consent.  In other words, if the Browser's peer uses DTLS-SRTP but not…

I'm not at all sure how DTLS-SRTP can be used as consent. ICE works as 
consent because there must be a shared out-of-band secret in order for 
the authentication to succeed.

DTLS-SRTP on the other hand can be negotiated with any cooperative far 
end, unless the far end is looking at a client-provided certificate, 
which seems unlikely.

> I don't believe we need to worry about consent for purely data-stream connections, assuming we pick either SCTP/UDP, SCTP/DTLS/UDP, or TCP/UDP; because there's a handshake of sufficient entropy.  B…

I don't think this is true either, because 1) if any other far end would 
do that handshake, you could connect to it without a shared secret (for 
instance, you could port-scan looking for SCTP/UDP thinks to talk to 
behind a firewall) and 2) As ekr said, I don't think there's enough 
entropy to prevent spoofing the consent either.

> I also believe there's one issue regarding consent which has not been documented: ICE-based or DTLS-based resource attacks.  If a malicious JS can trigger STUN-ICE, TURN-allocate, or DTLS-handshake…

Agree that the browser must enforce rate limits when sending to things 
that have not consented, no matter what the Javascript does.

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 28 Oct 2011 00:44:41 +0100

On 10/28/11 12:39 AM, Hadriel Kaplan wrote:
> ...
>    Heck, we could even mandate using a new TCP header option to be reflected by the other side, similar to the TCP Timestamp option, but put a random number in it.
>

Again, the STUN connectivity test used by ICE does more than simply 
prove that the far end got the packet and can reflect it back. The 
reflection isn't even done unless the long-term credentials are valid.

Matthew Kaufman

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 28 Oct 2011 00:32:37 +0000

On Oct 27, 2011, at 7:44 PM, Matthew Kaufman wrote:

> Again, the STUN connectivity test used by ICE does more than simply prove that the far end got the packet and can reflect it back. The reflection isn't even done unless the long-term credentials are valid.

Yes I know the ICE/STUN user/pass proves a shared secret, but what attacker/attack are you protecting against?

The JS obviously knows the ICE secrets, so the secret does not prevent the JS from spoofing to cause a hammer attack - only the reflected trans-id does.

A MitM may not know the secret, but if we didn't do ICE, what advantage could the MitM gain by responding to the TCP SYN or DTLS handshake?  If it's a MitM it can allow ICE to succeed anyway end-to-end, and then respond to the TCP SYN or DTLS.  

And I'm not suggesting just because they have a handshake that it makes TCP/UDP or SCTP/UDP secure from MitM eavesdropping or impersonation.  ICE doesn't either obviously.  I'm only saying that it makes it hard for a *non-MitM* to spoof.  

The main concern was that a malicious JS can cause a hammer/DDoS attack on another target, without being a MitM of the media-plane.  That's particularly difficult given RTP/RTCP have no handshake; or more to the point UDP has no handshake.  DTLS, TCP/UDP, and SCTP/UDP have it.  The question is if they're entropic enough to prevent the malicious JS from spoofing the handshake when it's not a MitM on the media-plane.  If the JS *is* a MitM on the media-plane, then the JS doesn't gain much by making the Browser perform the attack since the JS is now being attacked too.

No?  Maybe I'm missing something basic.

-hadriel

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 28 Oct 2011 02:07:08 +0100

> No?  Maybe I'm missing something basic.

The "malicious JavaScript" comes in the form of a banner ad, delivered 
to your web browser that is running behind your corporate firewall.

There is a public address system that plays whatever it receives over 
RTP out over the speakers in the building, with no signaling.

Without the ICE handshake, the banner ad can now play arbitrary media to 
the public address system once it finds the address. With the ICE 
handshake, that is prevented.

If that public address system also does DTLS-SRTP, and you don't require 
ICE in that case, the banner ad can *again* play arbitrary media to the 
public address system. Not acceptable.

There is also a SCTP/UDP controlled welding robot behind the firewall. 
With the ICE handshake, the browser can't command it to burn holes 
through the wall. Without the handshake, the browser can negotiate a 
SCTP/UDP connection to the robot and send it arbitrary commands. Also 
not acceptable.

Matthew Kaufman

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 27 Oct 2011 18:40:17 -0700

On 10/27/2011 04:44 PM, Matthew Kaufman wrote:
>>    Heck, we could even mandate using a new TCP header option to be 
>> reflected by the other side, similar to the TCP Timestamp option, but 
>> put a random number in it.
>>
>
Nit: the STUN usage I have seen so far uses short-term credentials 
(ephemeral username + password, RFC 5389 section 10.1) per RFC 5245 
section 7.1.2.3, not long-term credentials (realm + username + password, 
RFC 5389 section 10.2).

Since "short term" and "long term" are used with specific meaning in 
ICE, I hope we're using them in the same way in this discussion.

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 28 Oct 2011 02:56:46 +0000

On Oct 27, 2011, at 9:07 PM, Matthew Kaufman wrote:

> The "malicious JavaScript" comes in the form of a banner ad, delivered to your web browser that is running behind your corporate firewall.
> 
> There is a public address system that plays whatever it receives over RTP out over the speakers in the building, with no signaling.
> 
> Without the ICE handshake, the banner ad can now play arbitrary media to the public address system once it finds the address. With the ICE handshake, that is prevented.
> 
> If that public address system also does DTLS-SRTP, and you don't require ICE in that case, the banner ad can *again* play arbitrary media to the public address system. Not acceptable.
> 

Ahh right.  So the answer to the "Maybe I'm missing something basic" would be "yes".  :)
In fact I think you may have explained this once before and I've forgotten it 'cause now I'm getting deja vu.

> There is also a SCTP/UDP controlled welding robot behind the firewall. With the ICE handshake, the browser can't command it to burn holes through the wall. Without the handshake, the browser can negotiate a SCTP/UDP connection to the robot and send it arbitrary commands. Also not acceptable.

Hmmm, I'm not sure that would be possible... can you give me the IP:port of your welding robot? ;)

OK then, we need a per-session shared secret proof, as a form of per-session CORS in a way.
Will anything other than ICE accomplish it?

If we had a form of CORS, such that the host being sent RTP or SCTP/UDP or TCP/UDP published a list of allowed JS origins somehow, would that be sufficient?  For example if you're using your own Enterprise's Web Server and making a call to your own Enterprise's conference server or PSTN gateway or whatever from inside; if your conference server could somehow indicate "I trust JS from https://www.enteprise.com", similar to the Access-Control-Allow-Origin header.  

-hadriel

---

From: Randell Jesup <[email-masked]>
Date: Fri, 28 Oct 2011 01:52:33 -0400

> If we had a form of CORS, such that the host being sent RTP or SCTP/UDP or TCP/UDP published a list of allowed JS origins somehow, would that be sufficient?  For example if you're using your own En…

Since this has come up again...
I spent a while exploring CORS as an option privately with Cullen.  
Cullen shot down most of my ideas, though a limited version still 
survived, I think.    I'll quote from my last email on the subject:

    We'll start  by dropping the DNS-based approach.  Too bad, but I
    don't see a way to make it work securely.  A Forward-confirmed
    reverse-DNS lookup would be a good start, but that's spoofable in
    theory with enough work.  Close, but no cigar.   Though I'll digress
    into this for a second:

    The forward-confirmed reverse-dns approach is spoofable if the
    attacker can poison the DNS server or has sufficient MITM control to
    spoof DNS responses.  However, the ICE verification method is also
    spoofable if the attacker is in a MITM position, so the only real
    added vulnerability is to DNS poisoning.  While in general this
    might not be a reasonable DoS vulnerability, it might I suppose be
    relevant in targeted attacks.

    So we're left with CORS (using pre-flight) to the same IP address. 
    CORS is also vulnerable to MITM attacks if not over https (and as
    it's to an IP address, it's hard to validate the cert given has
    anything to do with the IP address, and so even https is in effect
    vulnerable to MITM).

    Ignoring the MitM effect (and I believe ICE equally MitM-able), CORS
    has one big advantage over ICE - it only has to be done once every
    X, where X can be large (using max-age).  Another might be lower
    impact on Hadriel's SBC media processors.  They would have to roll
    it out to their SBCs/etc, but support for responding (tirvially) to
    an http request is much easier than responding to ICE - and they
    could in their data center re-route port 80 (or 443) traffic to a
    generic webserver and not touch the gateways.  That would require
    firewall changes, but might avoid having to touch the gateways.

    The question would be "is this workable now", and also "is this
    worth it?"

CORS in this case means CORS to the same IP address you want to verify 
consent with (probably signaled ahead of time by the JS app, so we know 
to skip ICE).  Note that the CORS request, while to the same IP address, 
does not have to be the same server - website routers can route the 
80/443 traffic to a different non-media server if you like, so the 
existing gateways wouldn't have to be touched.

There might be some other ways to leverage this class of idea (using a 
different port at the same IP, routed differently at the gateway's 
firewall) to provide consent authorization.

-- 
Randell Jesup
[email-masked]

---

From: Igor Faynberg <[email-masked]>
Date: Fri, 28 Oct 2011 12:11:16 -0400

It would be good to do that, but can we REALLY achieve this?..  
(Especially, the the "Heck," clause)?

Igor, ever the Pessimist

On 10/27/2011 7:39 PM, Hadriel Kaplan wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 28 Oct 2011 17:54:09 +0000

>   relevant in targeted attacks.

I don't know what the DNS proposal was, but in Matthew's inside-Enterprise-attack scenarios, if the MitM is inside the Enterprise then yes all bets are off; but a MitM of Javascript/HTTP and DNS outside the Enterprise would not be in a position to perform the attack directly, nor spoof ICE for Matthew's attack scenario.  So doing ICE is safer than using DNS for approval.

>   So we're left with CORS (using pre-flight) to the same IP address.    CORS is also vulnerable to MITM attacks if not over https (and as

It's nastier than even that possibly - the same IP Address providing CORS does not mean it'll end up being the same application process that gets the subsequent SCTP or RTP.  For example if you're running a virtual hosting site and share the same IP for multiple customer apps. Do people do that? (I would think lots of things would break if they do, but who knows)

A nastier example is corporate Firewall-NATs or Carrier-Grade-NATs (CGNs), where a ton of hosts are represented by a few IP addresses.  If you're doing this from outside of the Firewall/CGN to a host inside the Firewall/CGN, then getting a CORS approval from one port number means nothing about reaching the same host on another port.

>   firewall changes, but might avoid having to touch the gateways.

But on a single gateway/SBC doing ICE could be a lot easier than HTTP GETs.  It all depends on your system design/architecture and we can't know which ones are going to be used.  My only argument against ICE has been that doing ICE is harder than not doing it at all, and even if you do ICE then doing SHA-1 on a per-STUN-message basis is harder than not doing SHA-1. (where "harder" would mean more CPU cycles or more cost)

>   The question would be "is this workable now", and also "is this

Good question.  I think debating/considering it is free, other than consuming emails and brain cycles. :)

-hadriel

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 28 Oct 2011 11:25:06 -0700

> It's nastier than even that possibly - the same IP Address providing CORS does not mean it'll end up being the same application process that gets the subsequent SCTP or RTP.  For example if you're…
All web hosting companies host massive numbers of user sites on the same 
(set of) IP addresses.
I believe the big ones go into the hundreds of thousands of names 
(~=customers) per IP address.

Although, if you go to http://<ipaddress>/ you will usually get a "no 
such customer" page.
(try http://74.125.127.121/ which is one IP for www.alvestrand.com, for 
instance)

Things get more complex (along multiple dimensions) if you can ask the 
client to do the CORS request to http://<ipaddress>:port - in that case, 
if the IP address is a carrier grade NAT box, the attacker can 
potentially grab one port in order to reply to the CORS, and then attack 
other customers by feeding in other port numbers to the subsequent SCTP/RTP.

> Good question.  I think debating/considering it is free, other than consuming emails and brain cycles. :)
Ouch, that's expensive!