[sr-dev] [kamailio/kamailio] TOPOH module mask_ip errantly skips decoding encoded fields (#1222)
Joshua Riffle
notifications at github.com
Wed Aug 30 00:26:28 CEST 2017
The topoh module uses its `mask_ip` parameter to tag and identify fields that have been encrypted with its header value. As of Kamailio 4.4.6 code has been added to make sure that `mask_ip` is properly used in the request URI, or `Via`, or any other appropriate SIP header variable before it attempts to perform decryption. Here is a code block that was added at line 738 in `modules/topoh/th_msg.c`
```
/* Do nothing if ruri is not encoded */
if ((REQ_LINE(msg).uri.len<th_uri_prefix.len) ||
(strncasecmp(REQ_LINE(msg).uri.s,th_uri_prefix.s,th_uri_prefix.len)!=0))
{
LM_DBG("ruri [%.*s] is not encoded",REQ_LINE(msg).uri.len,REQ_LINE(msg).uri.s);
return 0;
}
```
This effectively skips any Request URIs that don't properly match the expected `th_uri_prefix` which is created using the `mask_ip` value assigned to `topoh`.
<!--
Explain what you did, what you expected to happen, and what actually happened.
-->
So if I set topoh's `mask_ip` and assume I have set a `mask_key`:
```
modparam("topoh", "mask_ip", "192.168.99.184")
```
Then an `ACK` message like this gets detected and decoded as expected:
```
ACK sip:192.168.99.184;line=sr-1IFG6oxISo4wSekmUolOBKVwbolIboxd6JdwS7xiUekISKPm10NH18Rz1uBZtTpG SIP/2.0
```
However, if one of my incoming carriers decides to be extra special and append port `:5060` to the request URI like this:
```
ACK sip:192.168.99.184:5060;line=sr-1IFG6oxISo4wSekmUolOBKVwbolIboxd6JdwS7xiUekISKPm10NH18Rz1uBZtTpG SIP/2.0
```
It gets skipped by topoh because it no longer detects this variation of the URI and I get a message like this:
```
Aug 29 21:36:10 ip-172-31-4-69 /usr/sbin/kamailio[4629]: DEBUG: topoh [th_msg.c:742]: th_unmask_ruri(): ruri [sip:192.168.99.184:5060;line=sr-1IFG
6oxISo4wSekmUolOBKVwbolIboxd6JdwS7xiUekISKPm10NH18Rz1uBZtTpG] is not encoded
```
### Troubleshooting
I thought I might be smart and tried to change the `mask_ip` to `192.168.99.184:5060` but this is additionally blocked by the code that validates `Via` headers in `/modules/topoh/th_msg.c` line 393:
```
/* Skip if via is not encoded */
if (via->host.len!=th_ip.len
|| strncasecmp(via->host.s, th_ip.s, th_ip.len)!=0)
{
LM_DBG("via %d is not encoded",i);
continue;
}
```
It only compares the `host` part of the VIA with the `mask_ip` parameter which is `192.168.99.184:5060` (including the port) and therefore doesn't match and is skipped in decoding.
#### Reproduction
1. Set `topoh` module `mask_ip` to any acceptable IP address
2. Attempt to handle any traffic from a carrier that adds `:5060` automatically to the end of its request URIs
3. The call will go through and then drop ~90 seconds due to incessant attempts of the Kamailio server attempting to reach the bogus `mask_ip` address
#### Debugging Data
I believe the above information is fairly plain. I have included the pertinent debug logs, but it is fairly well describing why `topoh` is not decoding certain lines that it should be.
#### Log Messages
Example of a line that should be decoded which is not being decoded because the incoming carrier has added `:5060` to the `mask_ip` used in the Request URI.
```
Aug 29 21:36:10 ip-172-31-4-69 /usr/sbin/kamailio[4629]: DEBUG: topoh [th_msg.c:742]: th_unmask_ruri(): ruri [sip:192.168.99.184:5060;line=sr-1IFG
6oxISo4wSekmUolOBKVwbolIboxd6JdwS7xiUekISKPm10NH18Rz1uBZtTpG] is not encoded
```
#### SIP Traffic
Example of a call that repeatedly attempts to access bogus `mask_ip` in its route because it is not detected by topoh for decoding after it is passed through a carrier which adds `:5060` to its Request URIs.
### Possible Solutions
No workarounds :(
I also don't have the option of asking carriers to change their standing policy of appending the port ":5060" but the validation efforts in the `topoh` module could be expanded to accept an undesignated port number in the URI or `topoh` could include a `mask_port` parameter so that it builds its URI to expect one in the request URI and in `Via` header fields.
When I have more time to work on the validation C code I will include some suggestions, but others may have a more informed philosophical approach.
### Additional Information
To see all changes to `th_msg.c`:
```
git diff 4.4.5 4.4.6 -- modules/topoh/th_msg.c
```
```
version: kamailio 4.4.6 (x86_64/linux) becbde
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: becbde
compiled on 10:23:24 Jun 16 2017 with gcc 4.4.7
```
* **Operating System**:
```
CentOS release 6.8 (Final)
Linux ip-172-31-4-69.us-west-2.compute.internal 2.6.32-642.3.1.el6.x86_64 #1 SMP Tue Jul 12 18:30:56 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1222
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20170829/d21bf045/attachment-0001.html>
More information about the sr-dev
mailing list