[Home]

Summary:ASTERISK-29264: Certain IAX2 authentication failures cause Asterisk to crash
Reporter:N A (InterLinked)Labels:crash
Date Opened:2021-01-27 09:34:09.000-0600Date Closed:2021-03-11 11:55:07.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/chan_iax2 Resources/res_crypto
Versions:16.16.0 18.2.0 Frequency of
Occurrence		Constant
Related
Issues:
is related toASTERISK-29272 chan_iax2: Full URIs don't implement secure media checks properly
Environment:Debian Linux 9 and 10, multiple Asterisk versions ranging from 13.23.1 to 13.38 to version 16. To my knowledge, all Asterisk versions with res_crypto are affected from the testing that has been done.Attachments:( 0) cli.txt
( 1) core-brief.txt
( 2) core-brief.txt
( 3) core-full.txt
( 4) core-full.txt
( 5) core-info.txt
( 6) core-info.txt
( 7) core-locks.txt
( 8) core-locks.txt
( 9) core-thread1.txt
(10) core-thread1.txt
Description:Versions affected: All versions of Asterisk with res_crypto.so loaded: This bug affects all known Asterisk versions from the testing that has been done on multiple different Asterisk machines on multiple versions of Debian Linux. The dump attached is from a 13.23.1 testing system.

This issue affects chan_iax2 and/or res_crypto. I initially thought it was the former, but it may be more of the latter.

IAX2 supports no, plaintext, md5, and rsa authentication, the latter two of which allow for encryption. It has been identified that Asterisk contains a bug that results in a crash in the following circumstance: Switch B requires MD5 authentication (i.e. it requires a secret) for some IAX2 user. Switch A places a call to Switch B with all the correct information, except it omits to provide any kind of secret (that is, the Dial string is IAX2/user@host/extension as opposed to IAX2/user:secret@host/extension). In this case, Switch A's Asterisk will immediately crash. Once Asterisk is manually started again, Asterisk runs normally until the next crash.)

This does not occur with plaintext authentication, it does not occur if an invalid IAX2 user is called, and it does not occur if the desired IAX2 user is called and a secret is provided that is not the right secret. It only occurs when the called IAX2 user requires an MD5 secret but NO secret at all is provided by the calling switch. RSA has not been tested at all.

I suspect this issue is related to Switch A not knowing how to handle the failed authentication negotiation with Switch B. In most such scenarios, Switch A will say "I don't know how to authenticate to..." and then time out or end the call with CHANUNAVAIL, as expected. In this case, it says "I don't know how to authenticate to..." and then immediately crashes.

If res_crypto is not loaded, Switch A cannot negotiate the authentication at all, so the call fails but the switch does not crash. Obviously, such a switch cannot make any encrypted IAX2 call.

What should be happening here is that Asterisk should simply fail the call with a CHANUNAVAIL result as in all other circumstances where an IAX2 call fails (e.g. wrong user, wrong plaintext secret, etc.) Instead, Asterisk just crashes.

Backtrace files from ast_coredumper attached.
Comments:By: Asterisk Team (asteriskteam) 2021-01-27 09:34:11.400-0600

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/].
By: Asterisk Team (asteriskteam) 2021-01-27 09:34:16.332-0600

Per the Asterisk versions page [1], the maintenance (bug fix) support for the Asterisk branch you are using has ended. For continued maintenance support please move to a supported branch of Asterisk. After testing with a supported branch, if you find this problem has not been resolved, please open a new issue against the latest version of that Asterisk branch.

Thanks!

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions
By: Asterisk Team (asteriskteam) 2021-01-27 09:35:09.188-0600

This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable.
By: N A (InterLinked) 2021-01-27 09:35:47.219-0600

Ast core dumper files
By: George Joseph (gjoseph) 2021-01-28 09:51:00.072-0600

I can't seem to reproduce this.  Can you give me the iax.conf files from both Switch A and Switch B or small sample iax.conf files that can reproduce the issue?  Be sure to remove any sensitive information.


By: N A (InterLinked) 2021-01-28 10:13:31.855-0600

Both switches must have res_crypto active and enabled.
I tested it on a switch that did not have many components enabled/installed (among them res_crypto), and authentication simply fails prematurely so the switch does not crash. As soon as it supports encryption, the switch crashes.

An IAX2 user like the following on Switch B:

[someiaxuser]
type=user
context=some-dialplan-context
auth=md5 ; must be MD5 (no bug with plaintext, have not tested rsa, obviously no issue if there is no auth at all)
secret=testing ; some secret

On Switch A:
Dial(IAX2/someiaxuser@fqdn.example.com/5551212)

^ That will crash Switch A

Dial(IAX2/someiaxuser:thewrongsecret@fqdn.example.com/5551212)

^ This will not, this will simply be CHANUNAVAIL as expected, but Switch A will not crash.

Happy to clarify other details if needed. Here's a general iax.conf [general]:
[general]
relaxdtmf=yes ; If your server has issues with DTMF this option may help
bandwidth=high
disallow=all
allow=ulaw
allow=alaw
allow=g722
jitterbuffer=no
tos=0x12
calltokenoptional=0.0.0.0/0.0.0.0
requirecalltoken=no
delayreject=yes ; for increased security against brute force attacks
autokill=yes
encryption=yes
trunk=yes

encryption=yes is probably the only important thing here.
By: George Joseph (gjoseph) 2021-01-28 10:40:26.334-0600

Heh.  As you were probably pasting your configs, I was able to reproduce it locally.  
Thanks.

By: George Joseph (gjoseph) 2021-01-28 14:41:47.524-0600

[~InterLinked] There are reviews up on Gerrit if you want to test.

By: N A (InterLinked) 2021-01-28 16:14:06.810-0600

Thanks, George,
 I tried first to add the changes myself to an existing Asterisk 13 chan_iax.c to see if that would work. Alas it did not, and obviously that is unsupported, but just wanted to see.

I then upgraded that system to the latest Asterisk 16 (16.16 to be exact), and patched IAX with the file above for v16. The crashes still happen as before, unfortunately. As soon as I dial a certain test #, Asterisk crashes immediately. What's different now is I don't even see any warnings or errors in the console before the crash. Nothing in either the debug or regular logs even with verbosity 10 everywhere.

I'm not sure if it has something to do with v16.16 not being the original Asterisk, but I patched chan_iax and then compiled from source, so I'm a bit puzzled. Am I testing changes properly?

Happy to try v18 as well, but I imagine if upgrading from 13 to 16 did not work with the patch then 18 might not either.
By: George Joseph (gjoseph) 2021-01-28 18:08:34.914-0600

Interesting.  What's the iax2 user config look like on switch A?
Can you compile with DONT_OPTIMIZE, recreate the crash, and post the ast_coredumper txt files?

By: N A (InterLinked) 2021-01-28 18:47:27.820-0600

astdump #2 from 16.16
By: N A (InterLinked) 2021-01-28 18:49:30.088-0600

Hi, George, I added another dump from 16.16

I compiled it with DONT_OPTIMIZE from the get go, anticipating this:

Switch A iax.conf:
[general]
relaxdtmf=yes
bandwidth=high
disallow=all
allow=ulaw
jitterbuffer=no
tos=0x12
calltokenoptional=0.0.0.0/0.0.0.0
requirecalltoken=no
autokill=no
encryption=yes

I didn't scrub the IAX endpoint from the log, so if you want to try that directly yourself, feel free. That's what I've been doing for testing.
By: George Joseph (gjoseph) 2021-01-29 07:57:34.846-0600

I don't see a log attached.  Did I miss it somewhere?

There's something weird with the backtraces.  If you look at the "thread1" files, there's no information in them.   It _should_ look something like this...
{code}
#0  0x00007f75713b9345 in AES_encrypt (in=<optimized out>, out=0x7f7510208cc0 "", key=<optimized out>) at crypto/aes/aes_core.c:1562
#1  0x00007f7560d3d991 in __ast_aes_encrypt (in=0x7f7510208820 "", out=0x7f7510208cc0 "", ctx=0x7f755c005334) at res_crypto.c:478
#2  0x00007f7562d2e7e5 in memcpy_decrypt (dst=0x7f7510208cc0 "", src=0x7f7510208850 "", len=32, dcx=0x7f755c005334) at chan_iax2.c:6394
#3  0x00007f7562d2eec4 in encrypt_frame (ecx=0x7f755c005334, fh=0x7f7510208cbc, poo=0x7f755c005614 "", datalen=0x7f75102089c0) at chan_iax2.c:6490
#4  0x00007f7562d2fc60 in iax2_send (pvt=0x7f755c004e80, f=0x7f7510209d50, ts=3, seqno=1, now=1, transfer=0, final=0) at chan_iax2.c:6696
#5  0x00007f7562d33f91 in __send_command (i=0x7f755c004e80, type=6 '\006', command=4, ts=3, data=0x0, datalen=0, seqno=1, now=1, transfer=0, final=0) at chan_iax2.c:7712
#6  0x00007f7562d3426a in send_command_final (i=0x300000000, type=0 '\000', command=0, ts=0, data=0x0, datalen=0, seqno=1) at chan_iax2.c:7755
#7  0x00007f7562d52cbe in socket_process_helper (thread=0x255c5f0) at chan_iax2.c:11774
#8  0x00007f7562d545ef in socket_process_helper (thread=0x0) at chan_iax2.c:11950
#9  0x00007f7562d54caa in iax2_process_thread (data=0x255c5f0) at chan_iax2.c:12053
#10 0x00000000005e6832 in dummy_start (data=0x2528770) at utils.c:1299
#11 0x00007f75711f03f9 in start_thread (arg=0x7f751020d640) at pthread_create.c:463
#12 0x00007f7570edc903 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
{code}

In any case, if you could provide the Switch A user config, that'd be great.

By: N A (InterLinked) 2021-01-29 08:41:44.584-0600

Sorry, by log I meant the core dump files.

Nothing was in the logs at all.

I'm not sure why, but I always get the no symbol thing in the thread files when using astdump. I do have DONT_OPTIMIZE.

The [general] I posted is the iax.conf [general] on both switches essentially. The users on each switch are only for receiving incoming calls. Outgoing calls always are made using a full IAX2 URI with the user and host (and secret, with the caveat if one is not provided but one is necessary, the calling switch crashes), so calling switch's IAX user entries are not used for outgoing calls.
By: George Joseph (gjoseph) 2021-01-29 08:51:27.124-0600

Ah, I understand now, thanks.

By: George Joseph (gjoseph) 2021-01-29 10:33:09.438-0600

OK, I think I've got it.  There was actually another issue...  With no defined peer, you can specify a username and secret in the dial string but there's no way to specify an auth method and "auth" wasn't valid in the [general] section.  So I added a few more checks AND now allow "auth" to be specified in [general].  You _will_ have to set it there or the call won't go through.

Give the updated reviews a try.

By: N A (InterLinked) 2021-01-29 10:43:11.036-0600

Hmm, I *assumed* (and maybe was wrong about this) that somehow the auth method was inferred from the negotiation. At least, it seemed to be working that way, as if the right secret was provided in the Dial string, I could correctly make calls regardless of whether the called switch was using plain text or MD5 authentication.

It seems like setting auth in general would break this by forcing a particular method. I don't necessarily always want to use MD5 authentication, just whatever the called peer is using. Is this information negotiated/communicated back to the calling switch? That's what it seemed to be doing to do either PT or MD5 authentication properly.

Just worried that if, say, the called switch is actually using plain text or no encryption instead, it would not work (RSA requires an IAX2 user present on both sides, if my understanding is correct, so I don't think there would be any issues here anyways). This all assumes there is no way to communicate the auth method in the dial string, even if known.

Hope this makes sense - if not, I can clarify. My worry here is interoperability between switches with differing authentication methods that may not be the same and/or known in advance. Would adding auth=md5 to [general] in iax.conf potentially break anything?
By: George Joseph (gjoseph) 2021-01-29 11:54:00.833-0600

You can specify multiple auth methods like {{auth=plaintext,md5}}.   Unfortunately, changing how iax2 negotiates encryption will require a bit more work and I may have to push this into our work queue.  I'll nose around a bit more first though.





By: N A (InterLinked) 2021-01-29 12:04:43.705-0600

Thanks, George - so could I put `auth=md5,plaintext` or something like that in [general] to support all methods? (I assume it's overridden if a per-user method is specified, like RSA with appropriate keys.)

I'd assume if both are supported the most secure one would be negotiated but I think that might be a different concern. Otherwise, does the order matter?
By: George Joseph (gjoseph) 2021-01-29 12:19:33.489-0600

Correct on the "auth" line in [general] and yes, any options set on peers or users will override the defaults.  Order doesn't matter and I _believe_ the order tried is rsa, md5,
plaintext.  Don't forget, to enforce encryption, you need to set "forceencrypt=yes".



By: N A (InterLinked) 2021-01-29 12:28:49.699-0600

OK, super! That's essentially what I want. I will add that to my iax.conf on Switch A.

I don't have forceencrypt=yes, because I don't want to force encryption, I just want to use it if the called switch supports it. Otherwise, the call is unauthenticated/unencrypted.

However, I have been trying to do a per-call force encrypt type of thing where a user can elect to force encryption for that call and if the called switch does not support encryption (at least MD5 or RSA, since plaintext doesn't support encryption), then the call should fail. I've been trying to follow the instructions here: https://wiki.asterisk.org/wiki/display/AST/Secure+Calling+Specifics

Are we sure that this kind of thing is support by IAX?
exten => 123,n,Set(CHANNEL(secure_bridge_signaling)=1)
exten => 123,n,Set(CHANNEL(secure_bridge_media)=1)

However, if I don't set these and I read these variables on the called switch, they are set to 1 if the call was encrypted, so it seems like these are read only for IAX or something. Am I doing this right or is there another bug? Based on my testing, it seems like it should be supported but when I force encryption, somehow it doesn't recognize in advance that I am, in fact, providing a secret. Does it know in advance that it's MD5 or better, so it prematurely fails the call?

Whenever I see these, the call seems to fail, no matter what. The error was to the effect of "Force encrypt enabled but no secret provided"... except, I *was* providing the secret right in the dial string, and if I don't force encryption, the call goes through and it is encrypted, and these variables are 1 on the other end (empty otherwise).

Other examples indicate this has robust SIP support, but the IAX2 equivalents seem a bit buggy.
By: N A (InterLinked) 2021-01-29 12:49:23.296-0600

OK, so good news and bad news:

Good news: Asterisk no longer crashes! So, the bug itself is fixed.

For some reason, I don't hear any audio, but that may be another issue:

[Jan 29 18:43:18]     -- Executing [start@dialnpstn:9] Dial("Local/811@dt-ld-00000001;2", "IAX2/redacted@redacted/811,,g") in new stack
[Jan 29 18:43:18] WARNING[428][C-00000008]: chan_iax2.c:5132 iax2_call: Call terminated. Encryption requested but no secret provided
[Jan 29 18:43:18]     -- Couldn't call IAX2/redacted@redacted/811
[Jan 29 18:43:18]     -- Hungup 'IAX2/157.230.89.4:4569-14513'
[Jan 29 18:43:18]   == Everyone is busy/congested at this time (0:0/0/0)
[Jan 29 18:43:18]     -- Executing [start@dialnpstn:10] Goto("Local/811@dt-ld-00000001;2", "npstn-CHANUNAVAIL,1") in new stack
[Jan 29 18:43:18]     -- Goto (dialnpstn,npstn-CHANUNAVAIL,1)
[Jan 29 18:43:18]     -- Executing [npstn-CHANUNAVAIL@dialnpstn:1] Playback("Local/811@dt-ld-00000001;2", "custom/intercept/ACBN") in new stack
[Jan 29 18:43:18]     -- Local/811@dt-ld-00000001;1 answered IAX2/157.230.89.4:4569-11243
[Jan 29 18:43:18]     -- <Local/811@dt-ld-00000001;2> Playing 'custom/intercept/ACBN.ulaw' (language 'en')
[Jan 29 18:43:20] WARNING[428][C-00000008]: channel.c:1124 __ast_queue_frame: Exceptionally long voice queue length queuing to Local/811@dt-ld-00000001;1
[Jan 29 18:43:21] WARNING[329][C-00000008]: channel.c:1124 __ast_queue_frame: Exceptionally long voice queue length queuing to IAX2/157.230.89.4:4569-11243
[Jan 29 18:43:22] WARNING[428][C-00000008]: channel.c:1124 __ast_queue_frame: Exceptionally long voice queue length queuing to Local/811@dt-ld-00000001;1
[Jan 29 18:43:23] WARNING[428][C-00000008]: channel.c:1124 __ast_queue_frame: Exceptionally long voice queue length queuing to Local/811@dt-ld-00000001;1
[Jan 29 18:43:23] WARNING[336][C-00000008]: channel.c:1124 __ast_queue_frame: Exceptionally long voice queue length queuing to IAX2/157.230.89.4:4569-11243
[Jan 29 18:43:24] WARNING[323]: chan_sip.c:4140 retrans_pkt: Retransmission timeout reached on transmission 605611886-303334048-2145629343 for seqno 2 (Critical Response) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 32000ms with no response
[Jan 29 18:43:24] WARNING[428][C-00000008]: channel.c:1124 __ast_queue_frame: Exceptionally long voice queue length queuing to Local/811@dt-ld-00000001;1
[Jan 29 18:43:26] WARNING[428][C-00000008]: channel.c:1124 __ast_queue_frame: Exceptionally long voice queue length queuing to Local/811@dt-ld-00000001;1
[Jan 29 18:43:26]     -- Executing [npstn-CHANUNAVAIL@dialnpstn:2] Return("Local/811@dt-ld-00000001;2", "") in new stack

Bad news: It seems there is another bug with how the code is working. When I tried a call to an unencrypted #, it fails:

[Jan 29 18:43:41]     -- Executing [start@dialnpstn:9] Dial("Local/6460091@dt-ld-00000002;2", "IAX2/user@host.com/number,,g") in new stack
[Jan 29 18:43:41] WARNING[459][C-00000009]: chan_iax2.c:5132 iax2_call: Call terminated. Encryption requested but no secret provided

I never requested encryption for the call, and I didn't provide a secret. It seems like the auth=md5,plaintext in [general] in iax.conf is forcing authentication now. I'd imagine that unless I did something like:

Set(CHANNEL(secure_bridge_signaling)=1)
Set(CHANNEL(secure_bridge_media)=1)

unless forceencrypt=yes somewhere, then the call should not fail if there is no encryption, even if [general]'s auth is set. Or is that not how it is supposed to work?

If I misunderstood something or am doing something wrong, please let me know.

As an aside, whenever I patch Asterisk 16, it seems I need to reboot in order to restart Asterisk right, which I never experienced with v13, but that's not enough of an impediment enough to concern me at the moment. I'll give v18 a try as well after testing 16.
By: N A (InterLinked) 2021-01-29 13:01:16.041-0600

I am uploading the CLI output past the end of the last test calls I made. I haven't observed this kind of thing to this extent before, so I'm not sure if this is due to this change or something else, but for some reason it seems to not release the failed channels. Even channel request hangup all does not seem to work. This may be related to the other issue I was having though, so if this doesn't make sense, my guess it's unrelated. Just wanted to throw it up here in case.
By: George Joseph (gjoseph) 2021-01-29 14:12:47.377-0600

OK so...  I'm not sure how you're stopping or starting asterisk but "iax2 reload" doesn't reload everything (a but in itself maybe) so you must make sure the asterisk process goes away completely.  A reboot should NEVER be required.

Set(CHANNEL(secure_bridge_signaling)=1) and Set(CHANNEL(secure_bridge_media)=1) DO work for iax2 but you have to have at least encryption=yes in iax.conf set and the functions must be called on the "calling/incoming" channel (not in a pre-dial-handler).   I just tested it.

{code}
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@jac73/${EXTEN})
same  = n,Hangup()
{code}

At this point, I've reached the limit on the amount of time I can spend on this issue.  
Post in https://community.asterisk.org/ with any other questions.
If you think something else is broken, by all means open another issue.





By: N A (InterLinked) 2021-01-29 15:15:49.721-0600

Thank you, George. I will look into the CHANNEL encryption stuff more later - that's what I was doing essentially but I'll play around more later since that's off topic anyways.

More to the point, I upgraded from Asterisk 16 to 18 and that seemed to fix the weird issues I was having. I also deleted /usr/lib/asterisk during the upgrade but before doing so to clear out any old modules that weren't being used, so that may have helped as I did get a warning about this when going from 13 -> 16. So, I'm forgetting about the issues I had with 16 as I may not have been running a stable system. The 18 system is stable and works as expected.

With no auth= defined, every single outbound IAX call failed with:
[Jan 29 21:04:21] WARNING[597][C-00000011]: chan_iax2.c:5127 iax2_call: Call terminated. Encryption requested but no auth method provided

I tried with both auth=md5,plaintext in [general]. Regardless of order, I got a plaintext deprecated error, so I went with just auth=md5.
Now, encrypted calls succeed but I can no longer make unauthenticated calls to other switches. Some outbound calls have no secret provided in the dial string and the called switch does not support authentication, so these calls are not supposed to be encrypted. It seems like auth= in general is making encryption mandatory on all calls, which is breaking outbound calls that are not encrypted.

I tried auth=md5,none but that did not change.

On the calls that fail, I get this:

WARNING[804][C-0000002a]: chan_iax2.c:5132 iax2_call: Call terminated. Encryption requested but no secret provided

The other problem seems fully fixed in both Asterisk 16 and 18 so I think that is good to go, but I would not consider this 100% resolved yet if the fix unintentionally is preventing unencrypted calls from being made.

If this is a separate issue (which it doesn't seem to be, as this never happened before until now, with the auth=), I can file a new bug.

In any case, thank you very much for your help! I sincerely appreciate your time and all that you and the Asterisk devs put into this. I don't see a "Target Release" on this item, so how would I know which version will include the patch so I can upgrade ASAP when available?

Thanks again!
By: George Joseph (gjoseph) 2021-01-29 17:50:41.674-0600

OK, If the fix isn't actually working I can take a look more on Monday.   What I may have to do is turn encryption off for the call if no secret is specified and encryption isn't forced with either forceencryption or the CHANNEL set commands.

By: N A (InterLinked) 2021-01-29 18:10:24.590-0600

OK, yes, thanks, George, that's my understanding of what seems to be going on as well. It no longer crashes but it's crippled now in the other direction (with things that don't support encryption as opposed to those that require it), and I suspect this would actually break more people than it helped as is, but what you said I think is all that's off right now. Right now, encrypted calls work, the scenario that caused this bug is fixed, and all that is not working is the non-encrypted/authenticated scenario. I'll test changes again whenever the patch is updated. Thank you again!
By: George Joseph (gjoseph) 2021-02-03 14:42:47.347-0600

Go ahead and check out the latest patch.
The checks are now...
On an outgoing call,
* if forceencryption is set either in the conf file or by the channel variables AND the authmethods contains either MD5 or plaintext AND both the secret from the conf file and the secret from the dial string are empty or NULL, don't even try the call.
* when the peer sends back an auth request with encryption set AND the authmethods contains either MD5 or plaintext AND both the secret from the conf file and the secret from the dial string are empty or NULL, hangup the call.
By: N A (InterLinked) 2021-02-03 19:48:00.534-0600

Thanks, George. I think this is it now - I tested out a few different scenarios and all seems well. Works even without an auth= in [general] in iax.conf, so I think this should be very compatible and not break anything, either. The original bug is fixed, in that Asterisk no longer crashes, and I can call both #s that require authentication and that don't require authentication and it seems to be smart enough to know what to do depending on whether a secret is provided and/or whether one is required. In any case, I believe it now fixes the problem without breaking anything that wasn't working before, so thank you again!

Will there be a target release assigned to this change? We plan to upgrade everything in production ASAP as soon as this is in the next release.

I did find what appeared to be a bug with IAX2 force encrypt / channel secure media after all, but I filed a separate report about that so I won't expound on that here as it's unrelated to this bug.
By: George Joseph (gjoseph) 2021-02-04 08:04:37.248-0600

Cool!   The fix should go out in the next release, probably in about 3-4 weeks.

By: N A (InterLinked) 2021-03-11 11:52:03.363-0600

Hello, just wanted to follow up on this. I haven't done this many times so maybe I am just unfamiliar with the procedure, but a newer issue I submitted had a target version assigned to it today. This has been closed for ~6 weeks now and it doesn't have one attached. Is this just a mistake? I'd think given the severity it would make sense to go out in 18.3.0.
By: Asterisk Team (asteriskteam) 2021-03-11 11:52:03.804-0600

This issue has been reopened as a result of your commenting on it as the reporter. It will be triaged once again as applicable.
By: Joshua C. Colp (jcolp) 2021-03-11 11:54:46.942-0600

It looks like the JIRA issue was mistagged on the commit message. This is in the latest releases.