Details
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.
Attachments
Issue Links
- blocks
-
DISPATCH-1384 Fix tests in Travis CI on macOS
- Closed
- links to