Uploaded image for project: 'Qpid Proton'
  1. Qpid Proton
  2. PROTON-2122

Hardcoded limit of 16 sasl mechanisms is insufficient on macOS

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: proton-c-0.29.0
    • Fix Version/s: None
    • Component/s: proton-c
    • Labels:
      None
    • Environment:
      macOS 10.14

      Description

      On macOS, any time a SASL exchange happens in tests, e.g. cpp-example-container or qpid dispatch tests, or when cpp/examples/simple_send connects to cpp/examples/broker, the broker crashes with the following stack trace

      Thread 1 Crashed:
      0   libsystem_kernel.dylib              0x00007fff697c62c6 __pthread_kill + 10
      1   libsystem_pthread.dylib             0x00007fff69881bf1 pthread_kill + 284
      2   libsystem_c.dylib                   0x00007fff69730745 __abort + 144
      3   libsystem_c.dylib                   0x00007fff69730ff3 __stack_chk_fail + 205
      4   libqpid-proton-core.10.dylib        0x0000000106d81f89 pni_post_sasl_frame + 1321
      5   ???                                 0x00007fd57acb59bb 0 + 140554864908731
      

      AddressSanitizer (Valgrind does not run on most recent macOS releases) points out the reason.

      $ ../cmake-build-debug/cpp/examples/broker 
      broker listening on 5672
      =================================================================
      ==42793==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x70000c4bcbe0 at pc 0x0001013663e1 bp 0x70000c4bc830 sp 0x70000c4bc828
      WRITE of size 8 at 0x70000c4bcbe0 thread T3
          #0 0x1013663e0 in pni_split_mechs sasl.c:443
          #1 0x1013646ea in pni_post_sasl_frame sasl.c:480
          #2 0x101357fad in pn_output_write_sasl sasl.c:677
          #3 0x101323909 in transport_produce transport.c:2751
          #4 0x10131ffd3 in pn_transport_pending transport.c:3030
          #5 0x1012b8755 in pn_connection_driver_write_buffer connection_driver.c:120
          #6 0x10120240f in leader_process_pconnection libuv.c:909
          #7 0x1011f8b48 in leader_lead_lh libuv.c:1008
          #8 0x1011f94f3 in pn_proactor_wait libuv.c:1062
          #9 0x10188c55d in proton::container::impl::thread() proactor_container_impl.cpp:753
          #10 0x1018bca31 in void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, void (proton::container::impl::*)(), proton::container::impl*> >(void*) thread:352
          #11 0x7fff6987f2ea in _pthread_body (libsystem_pthread.dylib:x86_64+0x32ea)
          #12 0x7fff69882248 in _pthread_start (libsystem_pthread.dylib:x86_64+0x6248)
          #13 0x7fff6987e40c in thread_start (libsystem_pthread.dylib:x86_64+0x240c)
      
      Address 0x70000c4bcbe0 is located in stack of thread T3 at offset 192 in frame
          #0 0x101363ccf in pni_post_sasl_frame sasl.c:462
      
        This frame has 3 object(s):
          [32, 48) 'out' (line 464)
          [64, 192) 'mechs' (line 475) <== Memory access at offset 192 overflows this variable
          [224, 228) 'count' (line 478)
      HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
            (longjmp and C++ exceptions *are* supported)
      Thread T3 created by T0 here:
          #0 0x101f5dadd in wrap_pthread_create (libclang_rt.asan_osx_dynamic.dylib:x86_64+0x56add)
          #1 0x1018bc4ab in std::__1::thread::thread<void (proton::container::impl::*)(), proton::container::impl*, void>(void (proton::container::impl::*&&)(), proton::container::impl*&&) thread:368
          #2 0x10188da97 in proton::container::impl::run(int) proactor_container_impl.cpp:802
          #3 0x100f0223c in main broker.cpp:427
          #4 0x7fff6968b3d4 in start (libdyld.dylib:x86_64+0x163d4)
      
      SUMMARY: AddressSanitizer: stack-buffer-overflow sasl.c:443 in pni_split_mechs
      Shadow bytes around the buggy address:
        0x1e0001897920: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        0x1e0001897930: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        0x1e0001897940: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        0x1e0001897950: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        0x1e0001897960: 00 00 00 00 f1 f1 f1 f1 00 00 f2 f2 00 00 00 00
      =>0x1e0001897970: 00 00 00 00 00 00 00 00 00 00 00 00[f2]f2 f2 f2
        0x1e0001897980: 04 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
        0x1e0001897990: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        0x1e00018979a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        0x1e00018979b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        0x1e00018979c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      Shadow byte legend (one shadow byte represents 8 application bytes):
        Addressable:           00
        Partially addressable: 01 02 03 04 05 06 07 
        Heap left redzone:       fa
        Freed heap region:       fd
        Stack left redzone:      f1
        Stack mid redzone:       f2
        Stack right redzone:     f3
        Stack after return:      f5
        Stack use after scope:   f8
        Global redzone:          f9
        Global init order:       f6
        Poisoned by user:        f7
        Container overflow:      fc
        Array cookie:            ac
        Intra object redzone:    bb
        ASan internal:           fe
        Left alloca redzone:     ca
        Right alloca redzone:    cb
        Shadow gap:              cc
      ==42793==ABORTING
      Abort trap: 6
      

      The problem is that mechlist is (on my machine)

      "SRP SRP GS2-IAKERB GS2-KRB5 SCRAM-SHA-1 SCRAM-SHA-256 SCRAM-SHA-256 SCRAM-SHA-1 GS2-KRB5 GS2-IAKERB GSS-SPNEGO GSSAPI GSS-SPNEGO GSSAPI DIGEST-MD5 DIGEST-MD5 OTP OTP NTLM CRAM-MD5 NTLM CRAM-MD5 ANONYMOUS ANONYMOUS"
      

      which is over the limit of 16.

      This is not a security issue, because the mechanism list is created on server based on what cyrus-sasl mechs are installed. It is not based on data sent over the network.

      cc Andrew Stitcher, Roddie Kieley

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                jdanek Jiri Daněk
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated: