Comments (7)
sobomax
commented on May 29, 2024
1
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.
from rtpproxy.
sobomax
commented on May 29, 2024
That being said, we are working on few new mitigation features which could render this attack vector much more impractical.
from rtpproxy.
sandrogauci
commented on May 29, 2024
hi @sobomax would be happy to discuss potential solutions. My email: [email protected]
from rtpproxy.
lemenkov
commented on May 29, 2024
@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.
from rtpproxy.
sandrogauci
commented on May 29, 2024
@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.
from rtpproxy.
sobomax
commented on May 29, 2024
Well, there are two options we have on the table:
1. 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.
2. 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 ***@***.***> 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
<#70 (comment)>, 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
from rtpproxy.
durdo
commented on May 29, 2024
Do we have any update on this issue?
from rtpproxy.
Related Issues (20)
- socket allocated (SOCKET_REPLY) in technical docs is wrong? HOT 2
- rtpproxy briefly sends RTP from out-of-range source port and with unrelated RTP header fields before starting to properly forward HOT 4
- Difference between rtpp_weakref_obj and rtpp_hash_table HOT 1
- rtpproxy command protocol - stats - UDP stream timeout? HOT 2
- rtpp_acct_rtcp_hep - RTCP Type 203 (BYE)? HOT 2
- SIGSEGV in rtpp_wi_free HOT 2
- Play command fails HOT 7
- OSS-Fuzz issue 56543
- OSS-Fuzz issue 56764
- OSS-Fuzz issue 56786 HOT 1
- OSS-Fuzz issue 57069
- OSS-Fuzz issue 57278
- haw i can write RTCP code in c++
- OSS-Fuzz issue 59215
- What is the memory and CPU requirements for RTPProxy HOT 1
- Can't put all packets from both directions into a single file HOT 2
- OSS-Fuzz issue 59712
- Memory leak in `rtpp_cmd_rcache_insert` function HOT 1
- -Wincompatible-pointer-types configure check may fail unconditionally with future compilers
- SRTP support and 'transcoding' between encrypted and unencrypted streams
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rtpproxy.