[asterisk-bugs] [JIRA] (ASTERISK-27457) chan_sip: Guests disallowed via TCP (or TLS) if existing peer from same IP.

[Benjamin Keith Ford (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-27457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Benjamin Keith Ford updated ASTERISK-27457:
-------------------------------------------

    Comment: was deleted

(was: Thanks for the contribution! If you'd like your contribution to be included faster, you should submit your patch for code review by the Asterisk Developer Community. To do so, please follow the Code Review [1] instructions on the wiki. Be sure to:
* Verify that your patch conforms to the Coding Guidelines [2]
* Review the Code Review Checklist [3] for common items reviewers will look for
* If necessary, provide tests for the Asterisk Test Suite that verify the correctness of your patch [4]

When ready, submit your patch and any tests to Gerrit [5] for code review.

Thanks!

[1] https://wiki.asterisk.org/wiki/display/AST/Code+Review
[2] https://wiki.asterisk.org/wiki/display/AST/Coding+Guidelines
[3] https://wiki.asterisk.org/wiki/display/AST/Code+Review+Checklist
[4] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Test+Suite+Documentation
[5] https://wiki.asterisk.org/wiki/display/AST/Gerrit+Usage

)

> chan_sip: Guests disallowed via TCP (or TLS) if existing peer from same IP.
> ---------------------------------------------------------------------------
>
>                 Key: ASTERISK-27457
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27457
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/TCP-TLS
>    Affects Versions: 13.18.3, 15.1.3
>            Reporter: Alexander Traud
>         Attachments: allowguest_with_tcp.patch
>
>
> On default, Asterisk allows any peer to call extensions in the context named _default_. This is controlled via the parameter {{allowguest=yes}} in the configuration file _sip.conf_. That context must be specified in the dialplan configuration file _extensions.conf_. Such a peer does not need to be authorized - it can be a guest. This works if everyone is connected via UDP. This does not work if
> 1) the guest is connected via TCP (or TLS) and
> 2) a peer is connected from the same IP address already.
> Sounds unlikely. However, if the Asterisk is behind a NAT, and a registered peer is from the same NAT, and a guest (again from the same NAT) is trying to call via that Asterisk. That is even more likely, when that Asterisk is available via a fully-qualified domain-name (FQDN) and that FQDN offers a DNS-NAPTR entry. In that case, a good VoIP/SIP client prefers to connect via TLS. Consequently in such a scenario, both peers are connected via TLS.
> With the current source code, that second peer is not allowed as guest but is asked to authorize. The backtrace is:
> {code}handle_request_invite
> ↳ check_user_full
>   ↳ check_peer_ok
>     ↳ sip_find_peer
>       ↳ sip_find_peer_full
>         ↳ peer_ipcmp_cb_full{code}
> In {{check_peer_ok}}, the third/last call to {{sip_find_peer}} (that with the socket type as parameter value) returns not NULL (as with UDP) but the first TCP connected peer. Because of this, the subsequent source code returns the SIP message Unauthorized. This issue was caused as by [this change...| http://github.com/asterisk/asterisk/commit/4596fdb788435d8fe3fdf5c70afad718b6f214da] ([Review|http://reviewboard.asterisk.org/r/354/]). The referenced, previous [change was...| http://github.com/asterisk/asterisk/commit/fbad7a508d0c8d0b0c75474d2b7f9cbbcaa9b5e1] ([Review|http://reviewboard.asterisk.org/r/236/]).
> This issue was reported by [~stephane.chazelas] in July 2013 [already...|http://lists.digium.com/pipermail/asterisk-dev/2013-July/061526.html] The proposed workaround does not for for guests, therefore I report this issue today. As Stephane, I am not sure what [~dvossel] was about actually. Unfortunately, we cannot ask him anymore because he left the Asterisk platform in 2012.
> The attached patch fixes this because with TCP, each peer has its own source port. In other words: If the source ports differ, it cannot be the already connected peer, no matter which transport. Only if the ports match, the subsequent checks should be done.



--
This message was sent by Atlassian JIRA
(v6.2#6252)