The problem occurs when using NTLM (ie. not using -k) without providing the password. Here is the backtrace: Program received signal SIGSEGV, Segmentation fault. 0xb7dab8aa in memcpy () from /lib/tls/i686/cmov/libc.so.6 (gdb) bt #0 0xb7dab8aa in memcpy () from /lib/tls/i686/cmov/libc.so.6 #1 0xb76825c3 in msrpc_gen (mem_ctx=0x9ee5498, blob=0xbf92b328, format=0xb7adfa2d "CdBBUUUBd") at ../libcli/auth/msrpc_parse.c:156 #2 0xb75ac2da in ntlmssp_client_challenge (gensec_security=0x9ee2880, out_mem_ctx=0x9ee2960, in={data = 0x9ee5990 "NTLMSSP", length = 142}, out=0xbf92b328) at auth/ntlmssp/ntlmssp_client.c:257 #3 0xb75a95be in gensec_ntlmssp_update (gensec_security=0x9ee2880, out_mem_ctx=0x9ee2960, input={data = 0x9ee5990 "NTLMSSP", length = 142}, out=0xbf92b328) at auth/ntlmssp/ntlmssp.c:217 #4 0xb75a6fb9 in gensec_update (gensec_security=0x9ee2880, out_mem_ctx=0x9ee2960, in={data = 0x9ee5990 "NTLMSSP", length = 142}, out=0xbf92b328) at auth/gensec/gensec.c:983 #5 0xb75b619b in gensec_spnego_update (gensec_security=0x9ee2740, out_mem_ctx=0x9ee2960, in= {data = 0x9ee5b30 "�\201�0\201��\003\n\001\001�\f\006\n+\006\001\004\001\2027\002\002\n�\201\221\004\201\216NTLMSSP", length = 173}, out=0xbf92b454) at auth/gensec/spnego.c:1029 #6 0xb75a6fb9 in gensec_update (gensec_security=0x9ee2740, out_mem_ctx=0x9ee2960, in= {data = 0x9ee5b30 "�\201�0\201��\003\n\001\001�\f\006\n+\006\001\004\001\2027\002\002\n�\201\221\004\201\216NTLMSSP", length = 173}, out=0xbf92b454) at auth/gensec/gensec.c:983 #7 0xb759d5aa in ldap_bind_sasl (conn=0x9ee0ae8, creds=0x9eade48, lp_ctx=0x9ed1f38) at libcli/ldap/ldap_bind.c:320 #8 0xb759aa17 in ildb_connect (ldb=0x9edffb8, url=0xb7bec934 "ldap://192.168.99.2:389", flags=0, options=0x9ee08f0, _module=0x9edffb8) at lib/ldb/ldb_ildap/ldb_ildap.c:818 #9 0xb7578b09 in ldb_connect_backend (ldb=0x9edffb8, url=0xb7bec934 "ldap://192.168.99.2:389", options=0x9ee08f0, backend_module=0x9edffb8) at lib/ldb/common/ldb_modules.c:246 #10 0xb756fce4 in ldb_connect (ldb=0x9edffb8, url=0xb7bec934 "ldap://192.168.99.2:389", flags=0, options=0x9ee08f0) at lib/ldb/common/ldb.c:236 #11 0xb756abd5 in py_ldb_connect (self=0xb7beedec, args=0xb7bfe9dc, kwargs=0x0) at lib/ldb/pyldb.c:633 #12 0x080de562 in PyEval_EvalFrameEx () #13 0x080e00b8 in PyEval_EvalCodeEx () #14 0x081688c6 in ?? () #15 0x0806111a in PyObject_Call () #16 0x0806801a in ?? () #17 0x0806111a in PyObject_Call () #18 0x080b2c8e in ?? () #19 0x080ab6c1 in ?? () #20 0x0806111a in PyObject_Call () #21 0x080dcfea in PyEval_EvalFrameEx () #22 0x080e00b8 in PyEval_EvalCodeEx () #23 0x080e0217 in PyEval_EvalCode () #24 0x080fe0e1 in PyRun_FileExFlags () #25 0x080fe43a in PyRun_SimpleFileExFlags () #26 0x0805c882 in Py_Main () #27 0x0805b972 in main ()
Created attachment 4738 [details] Simple test case script. Works against S4 and w2k3 domain. ./demosegfault --remote-domain="smb4.tst" --host=192.168.99.2 -U SAMBA4\\administrator Segmentation fault ./demosegfault --remote-domain="smb4.tst" --host=192.168.99.2 -U SAMBA4\\administrator%totoTATA123
Should be fixed in "master".
Mathias, No not solved, have you tried running the script before closing the bug ? demosegfault --host=172.16.100.1 --remote-domain=home.matws.net -U MATWS\\administrator Here is the backtrace with gdb. Program received signal SIGSEGV, Segmentation fault. 0xb7bb8447 in talloc_chunk_from_ptr (ptr=0x6e808d76) at ../lib/talloc/talloc.c:231 231 if (unlikely((tc->flags & (TALLOC_FLAG_FREE | ~0xF)) != TALLOC_MAGIC)) { (gdb) bt #0 0xb7bb8447 in talloc_chunk_from_ptr (ptr=0x6e808d76) at ../lib/talloc/talloc.c:231 #1 0xb7bb99cb in _talloc_free (ptr=0x6e808d76, location=0xb7bc9c08 "lib/ldb/ldb_ildap/ldb_ildap.c:413") at ../lib/talloc/talloc.c:1118 #2 0xb7688491 in ildb_request_send (ac=0x838d768, msg=0x838d7b8) at lib/ldb/ldb_ildap/ldb_ildap.c:413 #3 0xb768873d in ildb_search (ac=0x838d768) at lib/ldb/ldb_ildap/ldb_ildap.c:485 #4 0xb7688f21 in ildb_handle_request (module=0x838a770, req=0x838ce40) at lib/ldb/ldb_ildap/ldb_ildap.c:738 #5 0xb76595b4 in ldb_request (ldb=0x8387670, req=0x838ce40) at lib/ldb/common/ldb.c:779 #6 0xb765aa15 in ldb_search (ldb=0x8387670, mem_ctx=0x838c2c0, result=0xbfffe684, base=0x838d480, scope=LDB_SCOPE_BASE, attrs=0xb7d17024, exp_fmt=0xb7bbdb21 "(objectClass=*)") at lib/ldb/common/ldb.c:1349 #7 0xb7657f30 in ldb_set_default_dns (ldb=0x8387670) at lib/ldb/common/ldb.c:143 #8 0xb765834b in ldb_connect (ldb=0x8387670, url=0x833f214 "ldap://172.16.100.1:389", flags=0, options=0x0) at lib/ldb/common/ldb.c:249 #9 0xb7652f1d in py_ldb_connect (self=0x83400a4, args=0x832be14, kwargs=0x0) at lib/ldb/pyldb.c:641 #10 0x080dc0d0 in PyEval_EvalFrameEx () #11 0x080dddf2 in PyEval_EvalCodeEx () #12 0x0816022f in ?? () #13 0x0806120a in PyObject_Call () #14 0x080684ac in ?? () #15 0x0806120a in PyObject_Call () #16 0x080aea8e in ?? () #17 0x080aa165 in ?? () #18 0x0806120a in PyObject_Call () #19 0x080dbc3c in PyEval_EvalFrameEx () #20 0x080dddf2 in PyEval_EvalCodeEx () #21 0x080ddef7 in PyEval_EvalCode () #22 0x080faa1f in PyRun_FileExFlags () #23 0x080fac12 in PyRun_SimpleFileExFlags () #24 0x0805c8d8 in Py_Main ()
I think I did test it - but I can't remember. It's always fine to reopen it again if you aren't satisfied with our resolution ;) . Also this has higher priority since it is a crash bug.
Found the reason why I closed this bug: it does only appear if you haven't specified your password (using %<password> directly after the username).
Fixed in "master".