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.

[Tommy]

Hello, 
I'm trying to apply this fix for rtpengine 13.4.1.8, basically: I add 3 flags "recrypt endpoint-learning-heuristic strict-source"
I make a call between 2 clients,  and things work well. 
A (port: A) ----------> (port: E1) RTPENGINE (port: E2) --------> (port: B) B

Then I try to simulate the attack  
./sprayrtp.py <RTPENGINE-IP>  <E1> <E1 +1> 

From this time, I got 1 way audio, when B does not hear the voice of A any more (A still hear B)

even I stop script, issue still 


Can I ask is this expected? or am I missing something? 

 

[Richard Fuchs]

On 02/10/2025 11.35, Tommy wrote:
> I'm trying to apply this fix for rtpengine 13.4.1.8, basically: I add
> 3 flags "recrypt endpoint-learning-heuristic strict-source"

Try again using `endpoint-learning=heuristic` (equals sign instead of dash).

Syntax is important.

Cheers

[Myng]

Hi Richard

I retest with rtpengine 13.5.1.1 with flag `recrypt endpoint-learning=heuristic strict-source` 
result still the same as 13.4.1.8 and "recrypt endpoint-learning-heuristic strict-source"

I'm unsure but it look like rtpengine, block RTP from origin IP, or under high intensive attack session can not recover

162.12.10.31 is attacker
45.133.169.174 is real phone
                                                                                                                                                                                               
[1760367804.763252] INFO: [oDV1LnAqVX/Ytho3sV0B/1 port 14656]: [core] Confirmed peer address as 45.133.169.174:35499                                                                                                                                                                                                                                                                                                                                                                                         
[1760367807.614406] INFO: [oDV1LnAqVX/Ytho3sV0B/1 port 14657]: [core] Confirmed peer address as 45.133.169.174:20282

[1760367907.356659] WARNING: [oDV1LnAqVX/Ytho3sV0B/1 port 14656]: [core] Discarded SRTP packet: decryption failed
[1760367907.356741] WARNING: [oDV1LnAqVX/Ytho3sV0B/1 port 14657]: [core] RTP packet with unknown payload type 0 received from 162.12.10.31:24628
[1760367907.356846] WARNING: [oDV1LnAqVX/Ytho3sV0B/1 port 14657]: [core] Discarded SRTP packet: decryption failed
[1760367907.359223] WARNING: [oDV1LnAqVX/Ytho3sV0B/1 port 14656]: [core] Too many packets in UDP receive queue (more than 50), aborting loop. Dropped packets possible
[1760367907.360064] WARNING: [oDV1LnAqVX/Ytho3sV0B/1 port 14657]: [core] Too many packets in UDP receive queue (more than 50), aborting loop. Dropped packets possible
[1760367907.363771] WARNING: [oDV1LnAqVX/Ytho3sV0B/1 port 14656]: [core] UDP receive queue exceeded 5 times: discarding packet
[1760367907.364151] WARNING: [oDV1LnAqVX/Ytho3sV0B/1 port 14657]: [core] UDP receive queue exceeded 5 times: discarding packet

--
You received this message because you are subscribed to a topic in the Google Groups "Sipwise rtpengine" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/rtpengine/wV4H_eni3-U/unsubscribe.
To unsubscribe from this group and all its topics, send an email to rtpengine+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/rtpengine/17464296-6e83-4722-b48b-23087ece0607%40sipwise.com.

[Richard Fuchs]

On 14/10/2025 03.52, Myng wrote:

                                                                                                                                                                       
[1760367804.763252] INFO: [oDV1LnAqVX/Ytho3sV0B/1 port 14656]: [core] Confirmed peer address as 45.133.169.174:35499                                                                                                                                                                                                                                                                                                                                                                                         
[1760367807.614406] INFO: [oDV1LnAqVX/Ytho3sV0B/1 port 14657]: [core] Confirmed peer address as 45.133.169.174:20282

[1760367907.356659] WARNING: [oDV1LnAqVX/Ytho3sV0B/1 port 14656]: [core] Discarded SRTP packet: decryption failed
[1760367907.356741] WARNING: [oDV1LnAqVX/Ytho3sV0B/1 port 14657]: [core] RTP packet with unknown payload type 0 received from 162.12.10.31:24628
[1760367907.356846] WARNING: [oDV1LnAqVX/Ytho3sV0B/1 port 14657]: [core] Discarded SRTP packet: decryption failed
[1760367907.359223] WARNING: [oDV1LnAqVX/Ytho3sV0B/1 port 14656]: [core] Too many packets in UDP receive queue (more than 50), aborting loop. Dropped packets possible
[1760367907.360064] WARNING: [oDV1LnAqVX/Ytho3sV0B/1 port 14657]: [core] Too many packets in UDP receive queue (more than 50), aborting loop. Dropped packets possible
[1760367907.363771] WARNING: [oDV1LnAqVX/Ytho3sV0B/1 port 14656]: [core] UDP receive queue exceeded 5 times: discarding packet
[1760367907.364151] WARNING: [oDV1LnAqVX/Ytho3sV0B/1 port 14657]: [core] UDP receive queue exceeded 5 times: discarding packet

That's an entirely different scenario and is not related to RTP bleed or injection. It's simply overloading the RX processing queue.

If you want to test against RTP bleed/inject then your test should actually test for just that. 😆

Cheers

[Tommy]

Thanks Richard for your response. 

Can we consider it is a bug or something should be fixed

[Richard Fuchs]

On 15/10/2025 08.26, Tommy wrote:
> Thanks Richard for your response.
>
> Can we consider it is a bug or something should be fixed

Not a bug since there's no promise of handling such a situation. It
could certainly be improved, although it might be difficult to do in
practice since excessive ingress traffic might need to be blocked on a
lower level.

Cheers