Stefan Sayer wrote:
Andres wrote:
It immediately jumped into my mind that this could be a security vulnerability since a remote attacker could effectively bring down all sessions on an rtpproxy just by doing a UDP scan.
...wouldn't they switch back to the correct addresses when the next RTP packet arrives, i.e. after 10/20/30 ms?
No it does not. I tried it. RTPProxy only switches addresses once. Although it is trivial to edit the source code and allow rtpproxy to always listen and adjust to IP Address changes during the entire call.
so would the more secure fix maybe be to always allow a switch back to the original address? o streams with rtp from the original address would switch back the connection address
yes, I like it this way. RTPPRoxy is always ready to change the IP Address of the stream.
o streams with rtp from different address would be vulnerable only for the very short period of call setup, before the first packet arrived (which makes the switch to the correct address)
As it stands today, it is vulnerable for the entire duration of the call. If for example 5 minutes into the call, you get a packet from a different IP Address, it switches the destination. (and stops listening for changes)
It turns out that we started investigating the issue due to loads of trouble at an ISP using D-Link ADSL modems. These modems are set to PPPoE and perform NAT. The problem is that its NAT is buggy. After call setup, every now and then it lets out a packet with the internal private IP Address of the SIP ATA as source, and naturally when the RTPProxy receives the packet it switches the media stream and it never switches it back when packets continue to flow in with the correct IP.
After the call was established, audio would fail as soon as this rtpproxy message appeared: caller's address filled in: 10.1.1.2:20014 (RTP)
The Ethereal trace revealed we received a packet from the private IP Address instead of the public one.
Andres http://www.neuroredes.com
Stefan
Andres http://www.neuroredes.com
Stefan
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers