[asterisk-bugs] [JIRA] (ASTERISK-29024) pjsip: Route Header in Cancel request incorrectly set
Ralf Kubis (JIRA)
noreply at issues.asterisk.org
Thu Oct 8 09:06:36 CDT 2020
[ https://issues.asterisk.org/jira/browse/ASTERISK-29024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=252370#comment-252370 ]
Ralf Kubis edited comment on ASTERISK-29024 at 10/8/20 9:05 AM:
----------------------------------------------------------------
I've experienced a similar, if not the same issue, and was able to identify the defective code after some debugging.
The symptom in my case was uninitialized data in the host-part of the URI of the CANCEL request.
Null-bytes in the string led to ISP-triggered hangups of the TCP-connection to a trunk of "Deutsche Telekom", and thereby a loss of my registration.
In other cases, without null-bytes, but other garbage, the CANCEL-request was ignored with an error reply, leading to continuous ringing on the called side.
Nevermind. The issue is to be found in *<src_root>\res\res_pjsip_nat.c* in function {{rewrite_uri(...)}}
There is the call
{{pj_cstr(&uri->host, rdata->pkt_info.src_name);}}
which produces a shallow copy. {{uri->host}} then 'points' to the same memory as {{rdata->pkt_info.src_name}}.
Later, in the defective case, {{uri->host}} gets evaluated after {{rdata->pkt_info.src_name[]}} was released from the pool (and the memory got re-assigned and used for other stuff).
As a fix, I've changed the signature of {{rewrite_uri()}} to
{{static void rewrite_uri(pjsip_rx_data *rdata, pjsip_sip_uri *uri, pj_pool_t *pool)}}
and in its body calling
{{pj_strdup2(pool, &uri->host, rdata->pkt_info.src_name);}}
to produce a deep-copy.
I think you've got the idea.
After short inspection I've identified a similar spot in {{websocket_on_rx_msg()}}.
In general I'd propose to review all other calls to {{pj_cstr()}} for this issue.
The current master still has this issue.
In case you need more details of how to reproduce and debug this, don't hesitate to contact me by email.
Thanks guys for your effort
was (Author: ralf.kubis):
I've experienced a similar, if not the same issue, and was able to identify the defective code after some debugging.
The symptom in my case was uninitialized data in the host-part of the URI of the CANCEL request.
Null-bytes in the string led to ISP-triggered hangups of the TCP-connection to a trunk of "Deutsche Telekom", and thereby a loss of my registration.
In other cases, without null-bytes, but other garbage, the CANCEL-request was ignored with an error reply, leading to continuous ringing on the called side.
Nevermind. The issue is to be found in *<src_root>\res\res_pjsip_nat.c* in function {{rewrite_uri(...)}}
There is the call
{{pj_cstr(&uri->host, rdata->pkt_info.src_name);}}
which produces a shallow copy. {{uri->host}} then 'points' to the same memory as {{rdata->pkt_info.src_name}}.
Later, in the defective case, {{uri->host}} gets evaluated after {{rdata->pkt_info.src_name[]}} was released from the pool (and the memory got re-assigned and used for other stuff).
As a fix, I've changed the signature of {{rewrite_uri()}} to
{{static void rewrite_uri(pjsip_rx_data *rdata, pjsip_sip_uri *uri, pj_pool_t *pool)}}
and in its body calling
{{pj_strdup2(pool, &uri->host, rdata->pkt_info.src_name);}}
to produce a deep-copy.
I think you've go the idea.
After short inspection I've identified a similar spot in {{websocket_on_rx_msg()}}.
In general I'd propose to review all other calls to {{pj_cstr()}} for this issue.
The current master still has this issue.
In case you need more details of how to reproduce and debug this, don't hesitate to contact me by email.
Thanks guys for your effort
> pjsip: Route Header in Cancel request incorrectly set
> -----------------------------------------------------
>
> Key: ASTERISK-29024
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-29024
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: pjproject/pjsip
> Affects Versions: 17.6.0
> Reporter: Flole Systems
> Assignee: Unassigned
>
> When I initiate a call using PJSIP and Cancel the call while it's still ringing the Route-Header seems to be sent incorrectly. It looks like it's a pointer to a memory region that got overwritten. I saw internal IP Addresses in there aswell as some other stuff like "Route: <sip:}". The "Route: <sip:" is always set properly, just the part after the sip is never set correctly and also the closing ">" is always missing.
> As the memory region that it reads from can't be controlled it might happen that confidential data like a password is exposed over this.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list