Hi,
I have a question regarding the way rtpproxy handles 'address filling'. After a session has been created, the rtpproxy pre-fills the caller and callee's addresses and we see that in the rtpproxy output like:
pre-filling caller's address with 192.116.246.234:41000 pre-filling callee's address with 192.116.246.234:20000
Then when it sees the actual packets coming in from a different source port, it updates the address and we see it in the log like: callee's address filled in: 192.116.246.234:1024 (RTP)
The audio then flows fine both ways.
My question is, what would happen it the actual packets came in from a different IP while the rtpproxy was waiting between the state of 'pre-filling' and 'address filled' states? Will the rtpproxy accept such a change that includes a new IP? Will it ignore packets from a different IP and continue the session normally? Or will it abort the session completely?
Thanks, Andres http://www.telesip.net
To answer my own question, I just set up a lab test to verify this.
After the session is up and the address has been 'pre-filled', if rtpproxy receives a packet on the same UDP port as one of the call legs but from a different IP, it changes the address to which it forwards the stream.
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.
I wanted to see if this was possible so I setup a new test with 32 concurrent calls on an rtpproxy server. The calls were setup and all streams were being forwarded correctly. I then used 'nmap' to scan all UDP ports used by rtpproxy. Initially nothing happened, but then I tried it again with a regular data_length and it effectively destroyed all sessions by pointing them to the nmap PC.
The rtpproxy console confirms the address change with 32 messages like these: callee's address filled in: 192.168.2.6:40318 (RTP) {this is the nmap PC} caller's address filled in: 192.168.2.6:40318 (RTP) {this is the nmap PC}
What do you think? Is this too far fecthed to worry about? Maxim, can you provide a fix that ignores IP Address changes and just acts on Port changes or does something critical break here? I can't think of a reason other than a bouncing DSL line that would require the rtpproxy server to worry about an IP Address change or a complicated NAT/Routing setup with multiple public IP Addresses.
Thanks, Andres
Andres wrote:
Hi,
I have a question regarding the way rtpproxy handles 'address filling'. After a session has been created, the rtpproxy pre-fills the caller and callee's addresses and we see that in the rtpproxy output like:
pre-filling caller's address with 192.116.246.234:41000 pre-filling callee's address with 192.116.246.234:20000
Then when it sees the actual packets coming in from a different source port, it updates the address and we see it in the log like: callee's address filled in: 192.116.246.234:1024 (RTP)
The audio then flows fine both ways.
My question is, what would happen it the actual packets came in from a different IP while the rtpproxy was waiting between the state of 'pre-filling' and 'address filled' states? Will the rtpproxy accept such a change that includes a new IP? Will it ignore packets from a different IP and continue the session normally? Or will it abort the session completely?
Thanks, Andres http://www.telesip.net
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Andres wrote:
I can't think of a reason other than a bouncing DSL line that would require the rtpproxy server to worry about an IP Address change or a complicated NAT/Routing setup with multiple public IP Addresses.
If you fork a call to multiple destinations and more than one starts doing early media or alternatively, if you have early media from one destination and final media from another, there will be a change in the source address of media. You will end up with no media on the actual call, if you don't accept the new addresses.
Regards, Martin
Hello,
I think this is an interesting question, but
Andres wrote:
To answer my own question, I just set up a lab test to verify this.
After the session is up and the address has been 'pre-filled', if rtpproxy receives a packet on the same UDP port as one of the call legs but from a different IP, it changes the address to which it forwards the stream.
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?
Stefan
Stefan Sayer wrote:
Hello,
I think this is an interesting question, but
Andres wrote:
To answer my own question, I just set up a lab test to verify this.
After the session is up and the address has been 'pre-filled', if rtpproxy receives a packet on the same UDP port as one of the call legs but from a different IP, it changes the address to which it forwards the stream.
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.
Andres http://www.neuroredes.com
Stefan
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 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)
Stefan
Andres http://www.neuroredes.com
Stefan
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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
Andres wrote:
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.
sorry, I was not precise:
so would the more secure fix maybe be to always allow a switch back to the original address?
... to the original address only?
so that a switch to an address away from the original address would be possible exactly once, but switching back to original address always.
this would also work with your D-Link modems.
Stefan
Stefan Sayer wrote:
Andres wrote:
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.
sorry, I was not precise:
so would the more secure fix maybe be to always allow a switch back to the original address?
... to the original address only?
so that a switch to an address away from the original address would be possible exactly once, but switching back to original address always.
Sure, that sounds good and more secure too. Maybe Maxim can chime in with his thoughts.
Andres http://www.neuroredes.com
this would also work with your D-Link modems.
Stefan
Stefan Sayer wrote:
so would the more secure fix maybe be to always allow a switch back to the original address?
... to the original address only?
so that a switch to an address away from the original address would be possible exactly once, but switching back to original address always.
But there is still forking. The way things work now is this: I detect the caller and at least one of the recipients of the INVITE to be NATed and activate RTP proxy. What happens is that RTP proxy returns an address and a port which nathelper puts into SDP for all branches.
Now consider the case where three devices are registered. They all start ringing. Two of them decide to not just say "180 Ringing" but to create early media. Which one does RTP proxy allow media from? In the current implementation, the UA that sends its media second wins. In the suggested implementation, the UA that sends its media first wins long term.
But: The third phone, which so far didn't do any media at all, is picked up. The two other branches are CANCELed, the early dialog is terminated, and the media streams end. The third phone wants to set up a media stream for the actual real call -- and is ignored by RTP proxy because it is considered an evil imposter.
Normally, you will not have this problem, because most UAs don't do early media. But the moment you do something fancy, like forking the call off to a PSTN number (eg., the user's cell phone) or playing a custom ringback tone, you are skrewed.
The only solution I can think of is to make RTP proxy branch aware. You could assign a separate port for each branch, but that is quite wasteful and will most likely exaust the ports rather quickly. I can't think of a way to correlate branches and media streams without knowing IP address and port, though. Anyone have a clever idea?
Maybe TURN isn't such a bad idea after all.
this would also work with your D-Link modems.
Ah, D-Link. What joy.
Regards, Martin
Andres andres@telesip.net wrote:
After the session is up and the address has been 'pre-filled', if rtpproxy receives a packet on the same UDP port as one of the call legs but from a different IP, it changes the address to which it forwards the stream.
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.
If this is concern for you, use option 'A' for commands. Asymmetric mode means destination can't be changed, but source with the same host, but another port, is accepted.
Default mode is designed for NAT traversal when external address detector (e.g. STUN) is absent or misworking. Security risk is other side of successful working under such conditions.
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.
Really there no such need, but we use variant when rtpproxy relearns for each packet in first 3 seconds after update/lookup command.
-
Andres -
Martin Hoffmann -
Stefan Sayer -
Valentin Nechayev