rtpproxy
rtpproxy copied to clipboard
sippy
CVE-2017-14114 / rtpbleed
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14114 was assigned for https://rtpbleed.com/, but I don't see any commits related to it, so not sure if that company who discovered it, actually reported it to you?
Hi, yes, this has been discussed with bug originators. Unfortunately due to the RTP limitations there is little can be done to support BOTH NAT traversal and be secure.
That being said, we are working on few new mitigation features which could render this attack vector much more impractical.
@sobomax @sandrogauci the problem that a client's port (and IP address) will likely change during session at least in some 4G networks. So it's a legitimate behaviour, and if rtpproxy detects IP:port change it really should start sending data to a new address. Apparently old IP:port pair must stop sending data in this case, but we can't use it as a solid "proof" to (dis)allow a new address because it could happen during some network glitch, "mute", or any other legitimate situation where client won't be able to send data.
Regarding SSRC - also can change during session.
So although I want to be positibe I don't see how it can be fixed easily. That's a problem with standards and protocols developed before network security in mind.
@lemenkov yes switching to a new IP is definitely one of the problems faced when trying to mitigate this by whitelisting an IP:port pair. My impression is that when this happens, the system could detect that the old IP:port pair did stop sending data and then allow the change to the new pair. Would you agree or disagree with this?
If there is a network glitch, the SSRC might not change. So I think adding some logic around different scenarios, e.g. when the SSRC does not change, allow the new IP:port pair; while when it does change, make sure that the session with the old SSRC is not still transmitting before allowing the switch to the new IP:port pair (which would require timing to be tuned).
Having said all that, of course this is an issue that is a limitation to plain RTP not providing any sort of authentication and not encrypting the traffic. So any changes to address this will just be mitigation rather than actual solutions to the underlying problem.
Well, there are two options we have on the table:
-
Use "honeyports", i.e. open UDP ports that we listen at but not use for actual sessions. We are allocate/deallocate say 1 of such port out of 10 real ports being open/closed. Should not add much load to the system. If any unsolicited traffic arrives at any of such ports then its' source IP[:port] into the "black list" and won't allow any packets from this particular source latch or re-latch other session. This would make "let me trick you into sending RTP to me" scenario impossible. All that is left is ability to DoS the service by sending packets from spoofed source IP.
-
We shall consider that incoming RTP stream has a proper timing between packets before allowing it to latch. So attacker would have to hit the same port repeatedly at least few times in order for this to have any effect. We can also consider holding up making a latching decision in the presence of multiple concurent streams, so that endpoint which could maintain its stream with a proper timing longest wins.
Mind you, since port allocation is essentially random, its actually a sort of a weak shared secret between us and legit UA. The problem is obviously that the key space is too small (i.e. 64K ports), so it's not difficult to brute force.
As Sandro correctly pointed out there is no "golden" bullet solution. But if say we would require attacked to bombard our host with 100,000 packets per second to dusrupt 1 session out of 5,000 active this makes the whole attack futile, as we essentially degraded DoS to a minor annoyance.
-Max
On Mon, Oct 9, 2017 at 6:33 AM, Peter Lemenkov [email protected] wrote:
@sobomax https://github.com/sobomax @sandrogauci https://github.com/sandrogauci the problem that a client's port (and IP address) will likely change during session at least in some 4G networks. So it's a legitimate behaviour, and if rtpproxy detects IP:port change it really should start sending data to a new address. Apparently old IP:port pair must stop sending data in this case, but we can't use it as a solid "proof" to (dis)allow a new address because it could happen during some network glitch, "mute", or any other legitimate situation where client won't be able to send data.
Regarding SSRC - also can change during session.
So although I want to be positibe I don't see how it can be fixed easily. That's a problem with standards and protocols developed before network security in mind.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sippy/rtpproxy/issues/70#issuecomment-335159263, or mute the thread https://github.com/notifications/unsubscribe-auth/AANWJkGCjeGdBaj1KlO3LsIjUJqY-Y2Kks5sqiCdgaJpZM4Plp32 .
-- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts Tel (Canada): +1-778-783-0474 <(778)%20783-0474> Tel (Toll-Free): +1-855-747-7779 <(855)%20747-7779> Fax: +1-866-857-6942 <(866)%20857-6942> Web: http://www.sippysoft.com MSN: [email protected] Skype: SippySoft
