From owner-freebsd-current@FreeBSD.ORG Tue Nov 23 18:39:35 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A49E16A4CF for ; Tue, 23 Nov 2004 18:39:35 +0000 (GMT) Received: from aiolos.otenet.gr (aiolos.otenet.gr [195.170.0.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48F9943D5C for ; Tue, 23 Nov 2004 18:39:33 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from orion.daedalusnetworks.priv (aris.bedc.ondsl.gr [62.103.39.226])iANIdVYk031276; Tue, 23 Nov 2004 20:39:31 +0200 Received: from orion.daedalusnetworks.priv (orion [127.0.0.1]) iANIdU54056405; Tue, 23 Nov 2004 20:39:30 +0200 (EET) (envelope-from keramida@linux.gr) Received: (from keramida@localhost)iANIdULA056404; Tue, 23 Nov 2004 20:39:30 +0200 (EET) (envelope-from keramida@linux.gr) Date: Tue, 23 Nov 2004 20:39:30 +0200 From: Giorgos Keramidas To: Wiktor Niesiobedzki Message-ID: <20041123183930.GA56352@orion.daedalusnetworks.priv> References: <20041123171951.GG3584@mail.evip.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041123171951.GG3584@mail.evip.pl> cc: current@freebsd.org Subject: Re: Putty or libcrypto bug? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2004 18:39:35 -0000 On 2004-11-23 18:19, Wiktor Niesiobedzki wrote: > Hi, > > When I try to run putty it dumps core. From what I found, it is triggered by > having nss_ldap configured to use TLS (ldaps://). The backtrace is folowing > > w@portal:~$ gdb =putty putty.core [...] > #0 sk_new (addr=0x0, port=1215526572, privport=-1077945272, oobinline=1215306875, nodelay=12, > keepalive=1215450516, plug=0x80e2614) at ../unix/uxnet.c:421 > 421 ../unix/uxnet.c: No such file or directory. > in ../unix/uxnet.c > (gdb) bt > #0 sk_new (addr=0x0, port=1215526572, privport=-1077945272, oobinline=1215306875, nodelay=12, > keepalive=1215450516, plug=0x80e2614) at ../unix/uxnet.c:421 > #1 0x487033de in sk_new_null () from /lib/libcrypto.so.3 > #2 0x48701c7b in CRYPTO_set_ex_data_implementation () from /lib/libcrypto.so.3 > #3 0x48701fb1 in CRYPTO_set_ex_data_implementation () from /lib/libcrypto.so.3 > #4 0x48702682 in CRYPTO_get_ex_new_index () from /lib/libcrypto.so.3 > #5 0x48684411 in X509_STORE_CTX_get_ex_new_index () from /lib/libcrypto.so.3 > #6 0x48619dae in SSL_get_ex_data_X509_STORE_CTX_idx () from /usr/lib/libssl.so.3 > #7 0x4861453d in SSL_CTX_new () from /usr/lib/libssl.so.3 > #8 0x485dced3 in ldap_pvt_tls_init_def_ctx () from /usr/local/lib/libldap-2.2.so.7 > #9 0x485dd400 in alloc_handle () from /usr/local/lib/libldap-2.2.so.7 > #10 0x485ddc6c in ldap_int_tls_connect () from /usr/local/lib/libldap-2.2.so.7 > #11 0x485dee8f in ldap_int_tls_start () from /usr/local/lib/libldap-2.2.so.7 > #12 0x485bc50c in ldap_int_open_connection () from /usr/local/lib/libldap-2.2.so.7 > #13 0x485ce7db in ldap_new_connection () from /usr/local/lib/libldap-2.2.so.7 > #14 0x485bbe81 in ldap_open_defconn () from /usr/local/lib/libldap-2.2.so.7 > #15 0x485ce297 in ldap_send_initial_request () from /usr/local/lib/libldap-2.2.so.7 > #16 0x485c3167 in ldap_sasl_bind () from /usr/local/lib/libldap-2.2.so.7 > #17 0x485c3ac5 in ldap_simple_bind () from /usr/local/lib/libldap-2.2.so.7 > #18 0x485a1cc0 in _nss_ldap_init () from /usr/local/lib/nss_ldap.so.1 > #19 0x485a1a92 in _nss_ldap_init () from /usr/local/lib/nss_ldap.so.1 > #20 0x485a2bbc in _nss_ldap_search_s () from /usr/local/lib/nss_ldap.so.1 > #21 0x485a3325 in _nss_ldap_getbyname () from /usr/local/lib/nss_ldap.so.1 > #22 0x485a4b59 in _nss_ldap_getpwuid_r () from /usr/local/lib/nss_ldap.so.1 > #23 0x483e3791 in __nss_compat_getpwuid_r () from /lib/libc.so.6 > #24 0x4844c7cb in nsdispatch () from /lib/libc.so.6 > #25 0x48422105 in getpwuid_r () from /lib/libc.so.6 > #26 0x482b14e0 in g_get_any_init () from /usr/local/lib/libglib12.so.3 > #27 0x482b1840 in g_get_home_dir () from /usr/local/lib/libglib12.so.3 > #28 0x481d6ad7 in gtk_rc_append_default_module_path () from /usr/X11R6/lib/libgtk12.so.2 > #29 0x481d6fc0 in gtk_rc_init () from /usr/X11R6/lib/libgtk12.so.2 > #30 0x481a9042 in gtk_init_check () from /usr/X11R6/lib/libgtk12.so.2 > #31 0x481a90f6 in gtk_init () from /usr/X11R6/lib/libgtk12.so.2 > #32 0x08071fb5 in pt_main (argc=1, argv=0xbfbfecb4) at ../unix/pterm.c:3270 > #33 0x080aad69 in main (argc=135144980, argv=0x80e2614) at ../unix/uxputty.c:140 > > As we may see, putty defines sk_new function and function of the same name > exists in libcrypto (in /usr/src/crypto/openssl/crypto/stack/stack.c). Good catch :-) This is a Bad Idea(TM) most of the time though. The library implements a function that other programs or libraries may depend upon to work in certain ways. Replacing the library function with a hand-rolled version may or may not work -- the latter in this case :-/ > And now my question: should the putty change the function name (what > sound wired) or there should be done some magic in libcrypto, so > such situations would not happen (what sounds tricky)? PuTTY can change the name of a function internal to the application a lot easier than a library. Changing the library affects all the programs linked to it, which is bound to be a lot more painful than changing putty.