[asterisk-bugs] [JIRA] (ASTERISK-29272) Full IAX2 URIs don't implement secure media checks properly

[Asterisk Team (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-29272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253678#comment-253678 ] 

Asterisk Team commented on ASTERISK-29272:
------------------------------------------

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. Please note that log messages and other files should not be sent to the Sangoma Asterisk Team unless explicitly asked for. All files should be placed on this issue in a sanitized fashion as needed.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur.

Please note that by submitting data, code, or documentation to Sangoma through JIRA, you accept the Terms of Use present at [https://www.asterisk.org/terms-of-use/|https://www.asterisk.org/terms-of-use/].

> Full IAX2 URIs don't implement secure media checks properly
> -----------------------------------------------------------
>
>                 Key: ASTERISK-29272
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29272
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_iax2
>    Affects Versions: 18.2.0
>         Environment: Debian 10, Asterisk 18.2. Same issue occurred with Asterisk 13.38, so presumably all Asterisk versions are affected.
>            Reporter: N A
>            Severity: Major
>
> According to: https://wiki.asterisk.org/wiki/display/AST/Secure+Calling+Specifics
> ${CHANNEL(secure_signaling)} and ${CHANNEL(secure_media)} allow for a per-call forceencrypt=yes setting.
> However, when I try to do this, the call fails with the error **Call terminated. No secret given and force encrypt enabled**.
> This occurs whether or not the provided secret is valid and even whether or not the provided hostname is valid. I tried with both the actual IAX2 endpoint as well as literally what is below, and I get the same exact results each time:
> ```
> [Jan 31 11:07:23]     -- Executing [18 at vsc:1] Set("Local/*18 at from-internal-000003b0;2", "__forcesecurechannel=1") in new stack
> [Jan 31 11:07:23]     -- Executing [18 at vsc:2] ExecIf("Local/*18 at from-internal-000003b0;2", "1?Set(CHANNEL(secure_bridge_signaling)=1)") in new stack
> [Jan 31 11:07:23]     -- Executing [18 at vsc:3] ExecIf("Local/*18 at from-internal-000003b0;2", "1?Set(CHANNEL(secure_bridge_media)=1)") in new stack
> [Jan 31 11:07:23]     -- Executing [18 at vsc:4] Dial("Local/*18 at from-internal-000003b0;2", "IAX2/main:somesecret at example.com/3475001,,g") in new stack
> [2021-01-31 11:07:23] WARNING[28425][C-00000417]: chan_iax2.c:5122 iax2_call: Call terminated. No secret given and force encrypt enabled
> [Jan 31 11:07:23]     -- Couldn't call IAX2/main:somesecret at example.com/3475001
> [Jan 31 11:07:23]     -- Hungup 'IAX2/93.184.216.34:4569-1658'
> [Jan 31 11:07:23]   == Everyone is busy/congested at this time (0:0/0/0)
> [Jan 31 11:07:23]     -- Executing [18 at vsc:5] NoOp("Local/*18 at from-internal-000003b0;2", "CHANUNAVAIL HANGUP CAUSE: 0") in new stack
> ```
> This makes no sense, as I am providing a secret and it literally says "No secret given". This seems to be a bug where Asterisk is preemptively ending the call where it (erroneously) detects no secret has been provided.
> A Digium developer tested a scenario out using these variables with calling an IAX2 destination and said it worked, confirming this functionality is supported for IAX2: https://issues.asterisk.org/jira/browse/ASTERISK-29264?focusedCommentId=253674&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-253674
> The example there was:
> ```
> exten = 9998,1,NoOp(Incoming to ${EXTEN} from ${CALLERID(all)})
> same  = n,Set(CHANNEL(secure_bridge_signaling)=1)
> same  = n,Set(CHANNEL(secure_bridge_media)=1)
> same  = n,Dial(IAX2/ernie:testing at jac73/${EXTEN})
> same  = n,Hangup()
> ```
> The only difference is jac73 appears to have a local iax.conf entry. In this case, that is not true, as all the info is in the dial string, with no local iax.conf entry.
> One thing that comes to mind is that Asterisk doesn't know at this point whether the secret on the remote peer is MD5 or plaintext, since the format is identical for both. But it can't know that without negotiating, and clearly it is not negotiating to determine that, and preemptively ends the call. The result is that IAX2 calling with a full IAX URI fails.
> To investigate, I created a local iax.conf user for the dial peer, just for kicks and giggles.
> With this user defined:
> [testing]
> type=friend
> context=main
> host=redacted.com
> it still did not work.
> With this user defined:
> [testing]
> type=friend
> context=main
> auth=md5
> host=redacted.com
> it still did not work.
> With THIS user defined:
> [testing]
> type=friend
> context=main
> auth=md5
> secret=thesecret
> host=redacted.com
> The call worked as expected - note however that a full IAX2 URI with the exact same information still fails:
> [Jan 31 11:18:13]     -- Executing [18 at vsc:4] Dial("Local/*18 at from-internal-000003bc;2", "IAX2/thesecret at redacted.com/3475001,,g") in new stack
> [2021-01-31 11:18:13] WARNING[29101][C-00000421]: chan_iax2.c:5122 iax2_call: Call terminated. No secret given and force encrypt enabled
> [Jan 31 11:18:13]     -- Couldn't call IAX2/main:thesecret at redacted.com/3475001
> [Jan 31 11:18:13]     -- Hungup 'IAX2/testing-3697'
> [Jan 31 11:18:13]   == Everyone is busy/congested at this time (0:0/0/0)
> [Jan 31 11:18:13]     -- Executing [18 at vsc:5] NoOp("Local/*18 at from-internal-000003bc;2", "CHANUNAVAIL HANGUP CAUSE: 0") in new stack
> [Jan 31 11:18:13]     -- Executing [18 at vsc:6] Dial("Local/*18 at from-internal-000003bc;2", "IAX2/main:wrighghoiwerhgoiergioerg at testing/3475001,,g") in new stack
> [Jan 31 11:18:13]     -- Called IAX2/thesecret at testing/3475001
> [Jan 31 11:18:13]     -- Call accepted by REDACTED:4569 (format ulaw)
> So, secure calling with IAX2 only seems to work if there is a locally defined user in iax.conf with both the auth method and the secret. IAX2 URIs do not work with secure calling at all. It seems Asterisk is preemptively ending the call if there is no iax.conf user, *even if a secret is provided in the dial string*. This bug prevents the ability to force a secure call when the IAX2 endpoint is an arbitrary IAX2 dial string as opposed to something predefined and preexisting in iax.conf, referenced by its local iax.conf name.
> Thus, currently, the ability to force encrypt an IAX2 call using the full URI is either buggy or nonexistent. This is a major loss in capability, since it is not always possible for there to be a corresponding iax.conf entry with the correct secret and what not for every call we might wish to make.
> The ideal behavior here as I see it would be to a) NOT preemptively and prematurely fail the call if there is no iax.conf entry and an IAX2 URI is provided *IF* a secret is provided and the call can negotiate as MD5 (if it's RSA, a dial string can't be used, and if it's plaintext, the call is not encrypted so it should presumably fail anyways... thus, such a call must be MD5).



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