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

[Michael Maier (JIRA)]

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

Michael Maier commented on ASTERISK-29230:
------------------------------------------

Regarding old logs (I have many of them until 2016):
Well, before asterisk 18.1, there wasn't any log output besides *DEBUG* (normally, I disable DEBUG output, because my device runs on a APU2 and SD-Card - that's why a massive amount of logentries is critical - they may break the complete system / SD-Card (I already had such a situation in the past)). The actual log output is an *ERROR* message which seems to didn't exist before 18.1. (I didn't search for it in the code so far).

The relation between the amount of ERROR lines (or DEBUG lines before in the same error situation) and the amount of Registers done before is highly suspicious to me. From my point of view, there aren't all old entries removed from an old register after a new reRegister has been performed.

> 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
>         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)