[asterisk-bugs] [JIRA] (ASTERISK-22861) [patch]Specifying a null time as parameter to GotoIfTime or ExecIfTime causes segmentation fault

[Corey Farrell (JIRA)]

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

Corey Farrell updated ASTERISK-22861:
-------------------------------------

    Attachment: ast_build_timing-initialize-timezone.patch

In addition to the applications you've mentioned this issue also applies to function IFTIME.  I've attached a patch that ensures timezone is always initialized by ast_build_timing.  This issue/patch applies to all supported branches + trunk.
                
> [patch]Specifying a null time as parameter to GotoIfTime or ExecIfTime causes segmentation fault
> ------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-22861
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-22861
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: PBX/General
>    Affects Versions: 11.5.1
>         Environment: Red Hat Enterprise Linux Server release 6.4 (Santiago)
> Kernel: 2.6.32-358.0.1.el6.x86_64
> HP DL 360 Server as well as VMWare virtual machine
>            Reporter: Sebastian Murray-Roberts
>         Attachments: ast_build_timing-initialize-timezone.patch, asterisk-11.5.1-TimeCheck.patch, asterisk-11.5.1-TimeCheck.patch
>
>
> I picked up this issue on one of our production servers, where we use GotoIfTime and ExecIfTime to control the opening and closing times of our call centres. The following lines of dialplan will cause Asterisk to seg-fault:
> {noformat}
> exten _X.,n,GotoIfTime(${DB(FOO/BAR)}?anylabel)
> OR
> exten _X.,n,ExecIfTime(${DB(FOO/BAR)}?anyapplication())
> {noformat}
> Where the AstDB entry FOO/BAR does not exist. We created these entries to allow for dynamically adjusting the times and setting certain parameters.
> What happens is that the *data parameter to pbx_builtin_execiftime and pbx_builtin_execiftim is passed as "?anylabel" or "?anyapplication()" this passes the initial test of whether *data is zero-length or not.
> In GotoIfTime, no errors regarding the format of the time are thrown, however the problem happens in the following lines:
> {code}
>  if (ast_build_timing(&timing, s) && ast_check_timing2(&timing, tv)) {
>                 branch = branch1;
>         } else {
>                 branch = branch2;
>         }
>         ast_destroy_timing(&timing);
> {code}
> ast_build_timing fails, as "s" is zero-length, this happens however at the top of the function before any other logic occurs. This means that the timing struct is never actually created and no memory is allocated to it. When ast_destroy_timing is called, it attempts to free timing->timezone which then causes a segmentation fault as timing has not explicitly been set to null, so it seems to pass the null check inside ast_destroy_timing. It then seems to be freeing a garbage pointer which causes the segmentation fault.
> The same issue happens inside pbx_builtin_execiftime in the following lines:
> {code}
> if (!ast_build_timing(&timing, s)) {
>                 ast_log(LOG_WARNING, "Invalid Time Spec: %s\nCorrect usage: %s\n", s, usage);
>                 ast_destroy_timing(&timing);
>                 return -1;
>         }
> {code}
> The only place ast_build_timing can return 0 is before the timing struct is actually initialized or created, so again when it tries to call ast_destroy_timing it attempts to free a garbage pointer and seg-faults.
> I have put a solution in place in both function currently which simply checks whether ast_build_timing returns non-zero and only if it does will it attempt to call ast_destroy_timing on the timing struct.
> This is probably a rather obscure bug, but thought it was worth bringing to your attention

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira