El Friday 14 December 2007 12:18:31 klaus.mailinglists@pernau.at escribió:
btw: IMO this is a bug in SIP. The RFC tells us that the SIP proxy should store the Contact URI and route calls based in this URI. But AFAIK the RFC does not tell us to validate the Contact URI.
Never trust user provided data blindly. The Contact is user provided :-(
I see other problem related:
Imagine a multidomain SIP proxy in which there are rules and filters between domains. For example:
- domain_A and domain_B in same proxy. - domain_A has a policy that dissallowes calls from domain_B. - But domain_B allowes calls from domain_A.
- sip:user_A@domain_A calls sip:user_B@domain_B - During the dialog user_B takes a look to received "Contact" from user_A.
- Later user_B sends a malicious REGISTER: ~# sipsak -U -C sip:user_A@Contact_user_A -a pw -s sip:user_B@domain_B
- Now user_B@domain_B calls himself and gets a call to user_A@domain_A. - So domain_A interdomain permissions rules have been bypassed :(
If NAT wouldn't exist in this IPv4 world, "Contact" header could be matched against the source IP of the REGISTER. But of course NAT makes it impossible.
Maybe OpenSer could add some security check to disallow "Contact" header containing public IP if the REGISTER is detected as natted. Could it be possible?