Asterisk
  1. Asterisk
  2. ASTERISK-17939

[patch] used auth= parameter freed during sip reload => crash

    Details

    • Type: Bug Bug
    • Status: Closed
    • Severity: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Target Release Version/s: 1.8.6.0
    • Labels:
      None

      Description

      Hi,

      if you use the auth= parameter and do a "sip reload" while there is an ongoing call. The peer->auth data points to free'd memory.

      Affected versions: -trunk and -1.6.2.x and probably every other version that has the auth= parameter in sip.conf.

      Because the memory is free'd before being re-allocated, in a test-setup there are chances that you get the same memory back and the crash doesn't occur. I've created a little patch that increases the likelyhood of getting a crash, so you can confirm the problem more easily.

      (And before you complain that I'm writing to free'd memory in that patch: that's to overcome any 0-setting of auth->next by ast_free. The kernel still thinks it's my memory and won't segfault over that.)

                • STEPS TO REPRODUCE ******

      sip.conf:

      [trunk]
      type=friend
      host=sip.itsp.tld
      auth=username:password@itsp.tld

      Open a CLI:

      *CLI> channel originate SIP/trunk/<somenumber> application Answer 20

      In the mean time, in another CLI:

      *CLI> sip reload

      Result:

      0x00007ffff74feb24 in strcasecmp () from /lib/libc.so.6
      (gdb) back
      #0 0x00007ffff74feb24 in strcasecmp () from /lib/libc.so.6
      #1 0x00007fffebaec150 in find_realm_authentication (authlist=0xe0b088, realm=0xe3d209 "itsp.tld") at chan_sip.c:26352
      #2 0x00007fffebac7f6a in build_reply_digest (p=0xe397d0, method=8, digest=0x7fffd82ba630 "", digest_len=1024) at chan_sip.c:18863
      #3 0x00007fffebaa7b7a in transmit_request_with_auth (p=0xe397d0, sipmethod=8, seqno=0, reliable=XMIT_RELIABLE, newbranch=1) at chan_sip.c:13336
      #4 0x00007fffeba83cab in sip_hangup (ast=0xe52cd0) at chan_sip.c:6253
      ASTERISK-1 0x000000000047671e in ast_hangup (chan=0xe52cd0) at channel.c:2849
      ASTERISK-2 0x000000000052a847 in async_wait (data=0xe37f18) at pbx.c:8514
      ASTERISK-3 0x000000000057a097 in dummy_start (data=0xe571a8) at utils.c:1010
      ASTERISK-4 0x00007ffff6d0d9ca in start_thread () from /lib/libpthread.so.0
      ASTERISK-5 0x00007ffff755e70d in clone () from /lib/libc.so.6
      ASTERISK-6 0x0000000000000000 in ?? ()
      (gdb) up
      #1 0x00007fffebaec150 in find_realm_authentication (authlist=0xe0b088, realm=0xe3d209 "itsp.tld") at chan_sip.c:26352
      26352 if (!strcasecmp(a->realm, realm))
      (gdb) print a
      $1 = (struct sip_auth *) 0xdeadbeef

                • ADDITIONAL INFORMATION ******

      As you can see, the problem is that peer->auth of an ongoing call is pointing to old auth= settings that have been free'd already.

      I don't have a quick-fix here. A ref-counter on the peer->auth value sounds like overkill. But you probably have a clever idea about how to fix this.

      Observe that the fact that I need a patch to get 100%-reproducible behaviour does not mean that it is a theoretical problem. This issue killed our production asterisken a couple of times yesterday.

      Regards,
      Walter Doekes
      OSSO B.V.

        Activity

        Hide
        Richard Mudgett added a comment -

        jira_asterisk_17939_v1.8.patch should take care of the crash. Minimal testing.

        Show
        Richard Mudgett added a comment - jira_asterisk_17939_v1.8.patch should take care of the crash. Minimal testing.
        Hide
        Richard Mudgett added a comment -

        Committed trunk -r326321.

        Merged revisions 326291 via svnmerge from
        https://origsvn.digium.com/svn/asterisk/branches/1.8

        ........
        r326291 | rmudgett | 2011-07-05 12:22:59 -0500 (Tue, 05 Jul 2011) | 23 lines

        Used auth= parameter freed during "sip reload" causes crash.

        If you use the auth= parameter and do a "sip reload" while there is an
        ongoing call. The peer->auth data points to free'd memory.

        The patch does several things:

        1) Puts the authentication list into an ao2 object for reference counting
        to fix the reported crash during a SIP reload.

        2) Converts the authentication list from open coding to AST list macros.

        3) Adds display of the global authentication list in "sip show settings".

        (closes issue ASTERISK-17939)
        Reported by: wdoekes
        Patches:
        jira_asterisk_17939_v1.8.patch (license #5621) patch uploaded by rmudgett

        Review: https://reviewboard.asterisk.org/r/1303/

        JIRA SWP-3526
        ........

        Show
        Richard Mudgett added a comment - Committed trunk -r326321. Merged revisions 326291 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r326291 | rmudgett | 2011-07-05 12:22:59 -0500 (Tue, 05 Jul 2011) | 23 lines Used auth= parameter freed during "sip reload" causes crash. If you use the auth= parameter and do a "sip reload" while there is an ongoing call. The peer->auth data points to free'd memory. The patch does several things: 1) Puts the authentication list into an ao2 object for reference counting to fix the reported crash during a SIP reload. 2) Converts the authentication list from open coding to AST list macros. 3) Adds display of the global authentication list in "sip show settings". (closes issue ASTERISK-17939 ) Reported by: wdoekes Patches: jira_asterisk_17939_v1.8.patch (license #5621) patch uploaded by rmudgett Review: https://reviewboard.asterisk.org/r/1303/ JIRA SWP-3526 ........

          People

          • Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - Not Specified
              Not Specified
              Remaining:
              Remaining Estimate - 0d
              0d
              Logged:
              Time Spent - 1m
              1m