Subject: [Perc] SSRC splicing attach in perc double when MID/BUNDLE is used (i.e. WebRTC)

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 21 Feb 2019 19:02:39 +0100

In the media framework it is stated the following regarding SSRC 
splicing attacks:

    The splicing attack is an attack where a Media Distributor receiving
    multiple media sources splices one media stream into the other.  If
    the Media Distributor is able to change the SSRC without the receiver
    having any method for verifying the original source ID, then the
    Media Distributor could first deliver stream A and then later forward
    stream B under the same SSRC as stream A was previously using.  By
    not allowing the Media Distributor to change the SSRC, PERC mitigates
    this attack.

However, if BUNDLE and MID are used, and there is no ssrc signaling done 
in SDP, the following RTP demuxing rules from BUNDLE spec applies:

    If the packet has a MID, and the packet's extended sequence number
    is greater than that of the last MID update, as discussed in
    [RFC7941], Section 4.2.6  <https://tools.ietf.org/html/rfc7941#section-4.2.6>, update the MID associated with the RTP
    stream to match the MID carried in the RTP packet, then update the
    mapping tables to include an entry that maps the SSRC of that RTP
    stream to the "m=" section for that MID.

Given that MID is by definition HBH as it must match the negotiated SDP 
O/A, then the MD could arbitrarily change the MID for an RTP packet and 
associate it with whatever transceiver it wishes, effectively having the 
same effect than the SSRC splicing attack (at least in perc double where 
all participants share the same inner e2e key and there).

Best regards

Sergio

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 21 Feb 2019 10:40:22 -0800

"By not allowing the Media Distributor to change the SSRC, PERC mitigates this
attack."

[BA] The security threat is mis-stated, and the "fix" is worse than the
problem.

In most situations modifying the SSRC will not represent an attack, just an
attempt on the part of the SFU to weave received simulcast streams together
to form a single stream so that an endpoint that does not support simulcast
reception can render it.  So the "fix" is inherently incompatible with
endpoints that can not receive simulcast, not a good tradeoff.

The actual threat to worry about is not "splicing" but "deep fakes" where
an attacker with access to cleartext audio and video can modify the media
(such as putting someone else's face on another body), while still
retaining synchronization between audio and video to make the "fake"
believable.  Addressing this kind of attack requires control of endpoint
access to cleartext media and recording APIs.  AFAICT, PERC does not
prevent this kind of attack because of key sharing.

"Given that MID is by definition HBH as it must match the negotiated SDP
O/A, then the MD could arbitrarily change the MID for an RTP packet and
associate it with whatever transceiver it wishes, effectively having the
same effect than the SSRC splicing attack (at least in perc double where
all participants share the same inner e2e key and there)."

[BA] MID modification is quite likely in scenarios such as "dominant
speaker" where the video (and audio) will switch between participants as
they take turns speaking.  Again, in most situations, this does not
constitute an attack, and where it does, PERC will not be of much help.

On Thu, Feb 21, 2019 at 9:57 AM Sergio Garcia Murillo <
[email-masked]> wrote:

> In the media framework it is stated the following regarding SSRC splicing
> attacks:
>
> _______________________________________________
> Perc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perc
>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 21 Feb 2019 21:38:29 +0100

Fully agree:

- The attack is not an attack but normal SFU behavior (the attack would 
be impersonation and/or deep fakes)
- Trying to prevent it, PERC forbids to rewriting ssrc which break most 
known SFUs up to date
- The attack is not prevented

IMHO PERC fails for WebRTC because it is not truly end to end, just 
browser to browser, as it doesn't take into consideration the role of 
the js app.

Only a e2ee solution integrated with IdP and isolated media streams 
which allows the receiver to assert the identity of the received packet 
would prevent impersonation and deep fakes. Without it, the user *MUST* 
trust the js application so that it doesn't send the media to an 
alternative server or create deep fakes as Bernard is stating.

Best regards
Sergio

On 21/02/2019 19:40, Bernard Aboba wrote:
> "By not allowing the Media Distributor to change the SSRC, PERC 
> mitigates this attack."
>
> [BA] The security threat is mis-stated, and the "fix" is worse than 
> the problem.
>
> In most situations modifying the SSRC will not represent an attack, 
> just an attempt on the part of the SFU to weave received simulcast 
> streams together to form a single stream so that an endpoint that does 
> not support simulcast reception can render it.  So the "fix" is 
> inherently incompatible with endpoints that can not receive simulcast, 
> not a good tradeoff.
>
> The actual threat to worry about is not "splicing" but "deep fakes" 
> where an attacker with access to cleartext audio and video can modify 
> the media (such as putting someone else's face on another body), while 
> still retaining synchronization between audio and video to make the 
> "fake" believable. Addressing this kind of attack requires control of 
> endpoint access to cleartext media and recording APIs.  AFAICT, PERC 
> does not prevent this kind of attack because of key sharing.
>
> "Given that MID is by definition HBH as it must match the negotiated 
> SDP O/A, then the MD could arbitrarily change the MID for an RTP 
> packet and associate it with whatever transceiver it wishes, 
> effectively having the same effect than the SSRC splicing attack (at 
> least in perc double where all participants share the same inner e2e 
> key and there)."
>
> speaker" where the video (and audio) will switch between participants 
> as they take turns speaking.  Again, in most situations, this does not 
> On Thu, Feb 21, 2019 at 9:57 AM Sergio Garcia Murillo 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     However, if BUNDLE and MID are used, and there is no ssrc
>     signaling done in SDP, the following RTP demuxing rules from
>     BUNDLE spec applies:
>
>     Given that MID is by definition HBH as it must match the
>     negotiated SDP O/A, then the MD could arbitrarily change the MID
>     for an RTP packet and associate it with whatever transceiver it
>     wishes, effectively having the same effect than the SSRC splicing
>     attack (at least in perc double where all participants share the
>     same inner e2e key and there).
>
>     Best regards
>
>     Sergio
>
>     [email-masked] <mailto:[email-masked]>

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 23 Feb 2019 19:11:00 -0700

> On Feb 21, 2019, at 11:02 AM, Sergio Garcia Murillo <[email-masked]> wrote:
> 
> In the media framework it is stated the following regarding SSRC splicing attacks:
> 
> However, if BUNDLE and MID are used, and there is no ssrc signaling done in SDP, the following RTP demuxing rules from BUNDLE spec applies:
> 
> Given that MID is by definition HBH as it must match the negotiated SDP O/A, then the MD could arbitrarily change the MID for an RTP packet and associate it with whatever transceiver it wishes, effectively having the same effect than the SSRC splicing attack (at least in perc double where all participants share the same inner e2e key and there).
> 
> 

No, it would not have the same effect at all.

---

From: Alexandre GOUAILLARD <[email-masked]>
Date: Sun, 24 Feb 2019 16:01:43 +0800

Cullen,

Would you mind to give more detail as to why you think it's different? From
where we stand, both approaches end-up deceiving the receiver into
believing some media is coming from one source while it's not. With that
definition of "effect", both the src splicing attack and Sergio proposed
attack have the same effect.
Agreed, PERC addresses the case where it is due to SSRC manipulation, but
if it does not address the other ways to achieve the same effect, it still
fail at protecting the receiver, at the perceived huge cost of removing the
capacity to support other important use cases cited before.

Do you have an implementation of PERC, as promised at IETF'99, for us and
others to test against?

Beyond the difference, do you think that the scenario sergio proposed:
- is a real problem ?
- should be addressed ?

Sergio,
feel free to prepare a working demo to make your point. If I understand
correctly, what you propose can be done today already quite easily.

-- 
Alex. Gouaillard, PhD, PhD, MBA
------------------------------------------------------------------------------------
President - CoSMo Software Consulting, Singapore
------------------------------------------------------------------------------------
sg.linkedin.com/agouaillard

   -