Bug 83 - When an Invite message has a header of Proxy-Authorization with invalid value, stack is unresponsive
Summary: When an Invite message has a header of Proxy-Authorization with invalid value...
Status: NEW
Alias: None
Product: resiprocate
Classification: Unclassified
Component: stack (libresip) (show other bugs)
Version: 1.9.5
Hardware: Other Linux
: P1 blocker
Assignee: Owner of all unassigned bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-22 04:59 CDT by amit_k_iitr
Modified: 2016-08-03 13:47 CDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description amit_k_iitr 2014-04-22 04:59:40 CDT
Hi,

When we pass the Invite message to stack, has a  Proxy-Authorization header with invalid value, it hangs, due to this our application is also become unresonsive.

In our application when we called the API parseAllHeaders with following Invite message, stack is got hang.

      INVITE sip:[service]@[remote_ip]:[remote_port] SIP/2.0
      Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
      From: "sut" <sip:7777@[local_ip]:[local_port]>;tag=[call_number]
      To: [service]<sip:[service]@[remote_ip]:[remote_port]>
      Call-ID: [call_id]
      CSeq: 1 INVITE
      Contact: <sip:7777@[local_ip]:[local_port];transport=[transport]>
      Max-Forwards: 70
      Content-Type: application/sdp
      Content-Length: [len]
      User-Agent: SIP Test Suite
      Proxy-Authorization: Digest =AKAv0-MD5

      v=0
      o=user1 53655765 2353687637 IN IP4 127.0.0.1
      s=-
      c=IN IP4 [media_ip]
      t=0 0
      m=audio [media_port] RTP/AVP 0 8 18
      a=rtpmap:0 PCMU/8000
      a=rtpmap:8 PCMA/8000
      a=rtpmap:18 G729/8000

Please look into the issue ASAP and let me know how to solve this issue.
Comment 1 amit_k_iitr 2014-04-22 06:29:16 CDT
Please find the backtrace of the above issue :

0x001b2d39 in resip::Auth::parseAuthParameters (this=0x9808960, pb=@0xbfe4ef5c) at ../../rutil/ParseBuffer.hxx:172
172                 if (cs.test((unsigned char)(*mPosition)))
(gdb) bt
#0  0x001b2d39 in resip::Auth::parseAuthParameters (this=0x9808960, pb=@0xbfe4ef5c) at ../../rutil/ParseBuffer.hxx:172
#1  0x001b319c in resip::Auth::parse (this=0x9808960, pb=@0xbfe4ef5c) at Auth.cxx:80
#2  0x0023dcf5 in resip::LazyParser::doParse (this=0x9808960) at LazyParser.cxx:79
#3  0x00227c9c in resip::ParserContainer<resip::Auth>::parseAll (this=0x9808928) at ../../resip/stack/LazyParser.hxx:106
#4  0x00293fb9 in resip::SipMessage::parseAllHeaders (this=0x9806880) at SipMessage.cxx:312
Comment 2 Daniel Pocock 2015-08-11 13:37:31 CDT
Did you have assertions enabled (not compiled with NDEBUG)?

I think that I have seen an assertion failure occur with such issues if assertions are enabled.
Comment 3 Daniel Pocock 2016-08-03 12:59:11 CDT
Is this fixed by commit b7429f08e051670205bb2a4e050fb7866878d483 ?

I observed something like this in a case where username="", not sure if the stack trace was the same however as it was a while ago.  I just tried to reproduce it with 1.10.0-1 and it doesn't crash.  I also tried it with a debug build from the master branch and it doesn't crash/assert either.
Comment 4 Philip Kizer 2016-08-03 13:27:30 CDT
Testing adding a reply #1.
Comment 5 Philip Kizer 2016-08-03 13:29:18 CDT
Testing adding a reply #1.
Comment 6 Philip Kizer 2016-08-03 13:29:51 CDT
Testing adding a reply #1.
Comment 7 Philip Kizer 2016-08-03 13:44:14 CDT
Testing adding a reply #1.
Comment 8 Philip Kizer 2016-08-03 13:46:26 CDT
Testing adding a reply #1.
Comment 9 Philip Kizer 2016-08-03 13:47:20 CDT
Testing adding a reply #1.