14 Dec
2007
14 Dec
'07
7:37 a.m.
El Friday 14 December 2007 12:18:31 klaus.mailinglists(a)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?
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es