Need clarification on the fix for RTP bleed vulnerability for DTLS-SRTP

[Kiran Ravuri]

Hi All

I came across ES2025-01: Rtpengine RTP Inject and RTP Bleed Vulnerabilities link yesterday. I couldn't understand how RTP bleed is applicable to DTLS-SRTP. 
My understanding so far was that remote candidates are derived after the ICE negotiation and any RTP packets coming from a different port than the ones derived from ICE are dropped before any processing.
Would someone care to explain what I am missing here?

BRs

Kiran

[Richard Fuchs]

This applies to a few different scenarios, but to my knowledge ICE was not involved in any of them. IOW there should not be (and hasn't been) a problem if ICE is in use.

Note that DTLS-SRTP does not mandate use of ICE nor the other way around, and so DTLS-SRTP can be used without ICE, as well as ICE can be used without SRTP.

Cheers

[Kiran Ravuri]

Apologies for the confusion. I wanted to ask for WebRTC use case where ICE is used.
Thanks for the clarification. 

[Sandro Gauci]

Hi Kiran,

Sorry to bring this up again. I wanted to explain the situation more clearly.

You're right to assume that an ICE check should have prevented RTP packets that come from an IPs and ports that were previously negotiated through ICE. However, in the current codebase, rtpengine only checks incoming DTLS packets against the ICE check in ice_peer_address_known().

RTP Bleed was therefore applicable before the fix because the learning mode ran before SRTP decryption. This would usually cause a Denial of Service (DoS). RTP Inject, on the other hand, in the case of DTLS-SRTP traffic, is not applicable because it fails the SRTP decryption. The attacker in this scenario does not have the correct encryption keys.

So yes, before the fixes applied in mr13.4.1.1, the text in our advisory is correct:

> There is the special case of DTLS-SRTP, typically used for WebRTC environments, which was found vulnerable to RTP Bleed but not RTP Inject. This was due to the logic applied in this case, where learning mode occurred before the RTP packets were properly validated. This has also received a security fix.

And:

> In the case of DTLS-SRTP, a fix was made so that SRTP validation occurs before learning mode. We highly recommend upgrading to access these security features.

In my presentation at ClueCon I had the following slide on this:

Full slides at https://drive.google.com/file/d/1YfAUOiRzwYcB-20DLyrInHCqpPGsq9qm/view?usp=sharing.

Hope this helps!

--

 

    Sandro Gauci, CEO at Enable Security GmbH

    Register of Companies:       AG Charlottenburg HRB 173016 B

    Company HQ:                       Neuburger Straße 101 b, 94036 Passau, Germany

    RTCSec Newsletter:               https://www.enablesecurity.com/subscribe/

    Our blog:                                https://www.enablesecurity.com/blog/

    Other points of contact:       https://www.enablesecurity.com/contact/

--

You received this message because you are subscribed to the Google Groups "Sipwise rtpengine" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rtpengine+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/rtpengine/b697e0a2-6438-4a6b-987a-539914498477n%40googlegroups.com.