[asterisk-bugs] [JIRA] (ASTERISK-29230) pjsip: Asterisk goes crazy and massively spams logfile if registration can't be send

[Asterisk Team (JIRA)]

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

Asterisk Team updated ASTERISK-29230:
-------------------------------------

    Target Release Version/s: 18.2.0

> pjsip: Asterisk goes crazy and massively spams logfile if registration can't be send
> ------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-29230
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29230
>             Project: Asterisk
>          Issue Type: Security
>      Security Level: None
>          Components: Channels/chan_pjsip
>    Affects Versions: 18.1.0
>         Environment: CentOS 7, x86_64
>            Reporter: Michael Maier
>            Assignee: Unassigned
>            Severity: Blocker
>              Labels: fax, patch
>      Target Release: 16.16.0, 18.2.0
>
>         Attachments: easybeltrace.png, forced-tcp-kill.tar.gz, no-abort.patch.tar.gz, obr_abort.patch
>
>
> If registration is impossible because of an error sending a packet, asterisk goes crazy and spams the log with > 6740(!) identical entries during 2 seconds like this one (-> no mediasec involved!):
> [2020-12-29 22:34:09] ERROR[4871] res_pjsip_outbound_registration.c: easybellPJSIP: Failed send registration to server 'sip:secure.sip.easybell.de' from client 'sip:[number]@secure.sip.easybell.de'
> There is a warning at the beginning of the spam attack:
> [2020-12-29 22:34:09] WARNING[3661] taskprocessor.c: The 'pjsip/outreg/easybellPJSIP-00000069' task processor queue reached 500 scheduled tasks.
> Another problem was at this time: The reRegistration started 14s too early (can't see any reason why)!  The first package seen in the pcap maps to the end of the timeline of the spam entries, means:
> - 6740 spam entries
> - first package seen in the pcap trace (written by asterisk)
> The account is a standard account, configured using tcp/tls.
> I consider this problem as a security problem, because it has the ability to kill a machine completely, depending on the machine's resources and the duration of the problem and the affected numbers in parallel (I could see the same problem some time later affecting 2(!) other numbers in parallel, but it luckily ended after about 0.1 seconds).



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