[Home]

Summary:ASTERISK-23790: [patch] - SIP From headers longer than 256 characters result in dropped call and 'No closing bracket' warnings.
Reporter:uniken1 (uniken1)Labels:
Date Opened:2014-05-26 23:19:34Date Closed:2014-06-26 05:08:00
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:SVN 1.8.26.1 11.10.2 12.2.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:CentOS 6.5Attachments:( 0) chan_sip-large-from-header-1.8.patch
( 1) chan_sip-large-from-header-1.8-r2.patch
( 2) chan_sip-large-from-header-1.8-r3.patch
( 3) chan_sip-large-from-header-11.patch
( 4) messages_2
( 5) messages_r3
( 6) myDebugLog
Description:[Edit by Rusty - The bracket is present in the packet - Asterisk receives it but stops parsing the From header before it gets to the bracket. I'm guessing due to a character length limit somewhere]

Asterisk drop call from trunk when SIP display info pressent in SIP invite packet. When I tcpdump packets I found that Asterisk incorrect parsing SIP packet. It said "No closing bracket found...", but bracket realy exists.
Check screens:
http://i64.fastpic.ru/big/2014/0526/cd/207e0e4f6924812d1bcdbe2b5283eacd.png
http://i64.fastpic.ru/big/2014/0526/ab/5764bee7a86881b6a29065396d554cab.png
Comments:By: Matt Jordan (mjordan) 2014-05-27 07:37:24.060-0500

We require a complete debug log to help triage the issue. This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information

Please make sure you have 'sip set debug on' enabled when collecting the log.

Note that your screen captures actually illustrate that there is no closing bracket (so Asterisk is right), but the debug information will prove one way or the other conclusively.
By: uniken1 (uniken1) 2014-05-27 22:34:31.498-0500

Debug log
By: uniken1 (uniken1) 2014-05-27 22:36:55.018-0500

If you check second screen(from Wireshark), you see closing bracket. Im highlight it.
By: Rusty Newton (rnewton) 2014-06-11 18:00:26.694-0500

Thanks for the debug log. I do see the closing bracket.

{noformat}
[May 28 07:29:09] DEBUG[28416] chan_sip.c:  Header  1 [ 65]: Via: SIP/2.0/UDP 10.214.104.121:5060;branch=z9hG4bK14aa2d13175ef3
[May 28 07:29:09] DEBUG[28416] chan_sip.c:  Header  2 [323]: From: "HelpDesk" <sip:8504@10.214.104.121;x-nearend;x-refci=19259122;x-nearendclusterid=StandAloneCluster;x-nearenddevice=SEP7C95F33EEDDF;x-nearendaddr=8555;x-farendrefci=19259121;x-farendclusterid=StandAloneCluster;x-farenddevice=SEP3C0E236D0240;x-farendaddr=8009>;tag=2946942~394ad5a3-1eb8-404e-81f1-1e37daf715dc-19259126
[May 28 07:29:09] DEBUG[28416] chan_sip.c:  Header  3 [ 29]: To: <sip:8505@10.214.104.255>
{noformat}

However it looks like Asterisk stops reading the header at around 256 characters. As it stops reading right at "... ;x-farendaddr=8' "

{noformat}
[May 28 07:29:09] WARNING[28416] sip/reqresp_parser.c: No closing bracket found in ' <sip:8504@10.214.104.121;x-nearend;x-refci=19259122;x-nearendclusterid=StandAloneCluster;x-nearenddevice=SEP7C95F33EEDDF;x-nearendaddr=8555;x-farendrefci=19259121;x-farendclusterid=StandAloneCluster;x-farenddevice=SEP3C0E236D0240;x-farendaddr=8'
[May 28 07:29:09] DEBUG[28416] sip/reqresp_parser.c: No supported scheme found in ' <sip:8504@10.214.104.121;x-nearend;x-refci=19259122;x-nearendclusterid=StandAloneCluster;x-nearenddevice=SEP7C95F33EEDDF;x-nearendaddr=8555;x-farendrefci=19259121;x-farendclusterid=StandAloneCluster;x-farenddevice=SEP3C0E236D0240;x-farendaddr=8' using the scheme[s] sip:,sips:
{noformat}

So. I'm no developer, but I'd suppose there is a character length limit to whatever variable or array the header is read into before being parsed.
By: Corey Farrell (coreyfarrell) 2014-06-11 18:58:22.320-0500

uniken1:

Please test one of attached patches (depending on your version).  I have not run this patch at all, so please test off-hours or on a non-production system.  I've created this patch based on the debug logs you provided, without looking into other possible related issues.  So if you still have an error be sure to post the new logs.
By: Richard Mudgett (rmudgett) 2014-06-12 15:37:31.426-0500

Corey:
Using ast_strdupa() on a string coming from the outside is a potential security vulnerability by blowing the stack.  A sanity limit either needs to be checked or the memory needs to be allocated.
By: Walter Doekes (wdoekes) 2014-06-12 16:14:20.224-0500

Richard: the sanity limit in this case is that it fits in a single SIP packet. Which is limited, either by UDP size or by this:

{noformat}
378269    mjordan #define SIP_MAX_PACKET_SIZE       20480  /*!< Max SIP packet size */
{noformat}

If you think that is not enough, that entire changeset needs to be revised.
By: Richard Mudgett (rmudgett) 2014-06-12 18:52:46.613-0500

Walter:
You're right.  However, there is the potential to put two 20k buffers on the stack from the changed function.
By: Corey Farrell (coreyfarrell) 2014-06-12 19:42:59.780-0500

Richard:
Unless I'm misunderstanding, 20k is the limit for the packet, so that would be the maximum total of "From", "Authorization" and all other headers combined.  I do somewhat agree though, we should avoid adding kilobytes to the stack.  I will improve the patch before submitting to reviewboard, but for now this should be good enough for the reporter to verify that this corrects the problem.
By: Walter Doekes (wdoekes) 2014-06-17 04:20:27.332-0500

uniken1: Could you try the attached patch and get back to us?
By: uniken1 (uniken1) 2014-06-18 08:01:15.290-0500

Sorry, I have install my asterisk from yum.
So to test patch I need deploy new environment from sources, so I need time...
By: uniken1 (uniken1) 2014-06-19 06:57:00.648-0500

I install Asterisk 1.8.26.1 from sources.
I try to install patch with command
cd /usr/local/src/asterisk-1.8.26.1
patch -p0 < chan_sip-large-from-header-1.8.patch
-bash: patch: command not found

So I manualy replace strings in chan_sip.c then
make
make install

Nothing changes. Same error.
By: Corey Farrell (coreyfarrell) 2014-06-19 11:39:45.736-0500

I recommend running:
bq. yum install patch

This is assuming you are running RHEL/CentOS/Scientific Linux.  If you are running a distro that uses a different package name then you may need to find it with:
bq. yum whatprovides *bin/patch

This way you can use the proper utility to apply patches in the future.  Also you said you previously had installed asterisk by yum.  Did you uninstall that copy?  If not it's possible you didn't run the manual build.  It could also be that /etc/asterisk/asterisk.conf still points the modules directory to the yum install instead of your manual install.  One thing you can do to be sure is insert a blank line at the beginning of chan_sip.c - verify that even if you get the same error message it should be from a new line number.
By: uniken1 (uniken1) 2014-06-19 23:10:31.117-0500

I install my production system by yum.
Now I deploy new clean CentOS 6.5 and asterisk from sources.

This output before patching:
[Jun 20 07:53:33] WARNING[29701]: sip/reqresp_parser.c:1061 get_in_brackets_full: No closing bracket found in '...
[Jun 20 07:53:33] NOTICE[29701]: chan_sip.c:16853 check_user_full: From address missing 'sip:', using it anyway
[Jun 20 07:53:33] WARNING[29701]: sip/reqresp_parser.c:1061 get_in_brackets_full: No closing bracket found in '...
[Jun 20 07:53:33] WARNING[29701]: chan_sip.c:16038 get_destination: Not a SIP header (<sip:2058648)?
[Jun 20 07:53:33] WARNING[29701]: sip/reqresp_parser.c:1061 get_in_brackets_full: No closing bracket found in '...
[Jun 20 07:53:33] NOTICE[29701]: chan_sip.c:16853 check_user_full: From address missing 'sip:', using  it anyway
[Jun 20 07:53:33] WARNING[29701]: sip/reqresp_parser.c:1061 get_in_brackets_full: No closing bracket found in '<...
[Jun 20 07:53:33] WARNING[29701]: chan_sip.c:16038 get_destination: Not a SIP header (<sip:2058648)?

Then patching
[root@as21448 asterisk-1.8.26.1]# patch -p0 < chan_sip-large-from-header-1.8.patch
patching file channels/chan_sip.c
Hunk #1 succeeded at 16809 (offset -43 lines).
Hunk #2 succeeded at 16897 (offset -43 lines).

And I add some empty lines at begin of file chan_sip.c

Output after patching:
[Jun 20 08:02:12] WARNING[1440]: sip/reqresp_parser.c:1061 get_in_brackets_full: No closing bracket found in '...
[Jun 20 08:02:12] WARNING[1440]: chan_sip.c:16043 get_destination: Not a SIP header (<sip:2058648)?
[Jun 20 08:02:12] WARNING[1440]: sip/reqresp_parser.c:1061 get_in_brackets_full: No closing bracket found in '...
[Jun 20 08:02:12] WARNING[1440]: chan_sip.c:16043 get_destination: Not a SIP header (<sip:2058648)?
By: Corey Farrell (coreyfarrell) 2014-06-23 01:37:26.370-0500

[~uniken1]:
Please try the r2 patch for 1.8.  This new patch addresses the buffer size issue in {{get_destination}} in addition to {{check_user_full}}.  Please note your new log is not the same as the old one, as the new one has no error's from {{check_user_full}}.

If you continue to have issues please post logs, even if they look the same to you.
By: uniken1 (uniken1) 2014-06-23 23:18:03.270-0500

After patch r2 it works. Thanks!
In log file only one string:
[Jun 24 08:08:21] NOTICE[32057] chan_sip.c: From address missing 'sip:', using it anyway
By: Corey Farrell (coreyfarrell) 2014-06-24 00:38:21.450-0500

Thanks for testing.  I'll get this posted for review so we can include this in a future release.
By: Walter Doekes (wdoekes) 2014-06-24 04:46:21.660-0500

[~uniken1]: > NOTICE[32057] chan_sip.c: From address missing 'sip:', using it anyway

Can you get a DEBUG log of the messages surrounding that?
By: uniken1 (uniken1) 2014-06-24 08:31:14.568-0500

debug logs 2
By: uniken1 (uniken1) 2014-06-24 08:34:36.287-0500

I added "messages_2" debug log.
I very surprized when I enable "sip set debug on" - Call drop.
When I disable it, call flow normal.
By: Walter Doekes (wdoekes) 2014-06-24 11:32:43.783-0500

uniken1: please try {{chan_sip-large-from-header-1.8-r3.patch}}.

Corey: *of was not supposed to get freed just yet.
By: uniken1 (uniken1) 2014-06-25 00:40:21.176-0500

Add file messages_r3
seems everything work fine.