[asterisk-bugs] [JIRA] (ASTERISK-29085) func_curl: Segmentation fault when using CURL after setting httpheader CURLOPT

[Benjamin Keith Ford (JIRA)]

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

Benjamin Keith Ford updated ASTERISK-29085:
-------------------------------------------

    Status: Open  (was: Triage)

> func_curl: Segmentation fault when using CURL after setting httpheader CURLOPT
> ------------------------------------------------------------------------------
>
>                 Key: ASTERISK-29085
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29085
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Functions/func_curl
>    Affects Versions: 16.8.0
>         Environment: Fedora 32 Linux x86_64
>            Reporter: Péter Juhász
>            Assignee: Unassigned
>            Severity: Minor
>         Attachments: gdb.txt
>
>
> The capability to set HTTP headers was recently added to Asterisk (in issue ASTERISK-28613), but it turns out that this functionality is unsafe in its current implementation, because it is possible to induce a segmentation fault with some combinations of CURLOPT calls.
> The steps to reproduce:
> - Set CURLOPT(httpheader)=Content-Type: application/json
> - use CURL to send POST JSON data to some HTTPS service
> - Set some other CURLOPT that is not httpheader (e.g. userpwd, httptimeout)
> - use CURL again
> With such a dialplan Asterisk crashes consistently.
> We have a coredump, but it contains potentially sensitive data, so I don't want to upload it to the public tracker.
> Analyzing the coredump, it appears that curl->set.headers in acf_curl_helper contains garbage, or more precisel, the data and next pointers in that structure became stale since the first call to CURL. 



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