From libssh2-devel-bounces@cool.haxx.se Mon Feb 16 16:24:05 2015 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-7) with ESMTP id t1GFNaaQ016513; Mon, 16 Feb 2015 16:24:01 +0100 Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by giant.haxx.se (8.14.4/8.14.4/Debian-7) with ESMTP id t1GFNYHx016421 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 16 Feb 2015 16:23:35 +0100 Received: by mail-qc0-f182.google.com with SMTP id r5so10914792qcx.13 for ; Mon, 16 Feb 2015 07:23:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=qM2MDQ+DrCmkzuH0NBGGpglYTyK6pqMDQNchCu33kqE=; b=Qjm4YQSLMBCrakCgMbqbkuPYPOWqo4apzDeyG0jJR7LDeFc6zLAgdGhnEfOUW/CJSE R2skE76vyfEYGWpu44YKwnuqnRAPa8mELrcZhcNlr1PtJATTT+n7JYnOjoDMJa/FRB7r oCLoiKNXkpSmt0NPTRao6iV7kRq+FEgo7SaXdxorOjMznVAQFlUPYs2bSNrncnf/UBBu 9R5q2IlIBWRASrj09hqMisNPSqjnkc5AB8P1jEdG4S1ElxLHqFeubgFJi0plcAVTBVOY 6f+R2+78YB1ZpmgMKQUXq+lYwhz34sh6LdxjqVanPRhPB+T6xhY58xYGS2WT7zmk7YYB 1LNA== X-Gm-Message-State: ALoCoQkypb84YkV2l1CL9GjNFAsXsHHJXVchpBfA07Q/tvTMOVAw70IYvupSdWE7i10rxaUH8NnL MIME-Version: 1.0 X-Received: by 10.141.23.1 with SMTP id z1mr2637939qhd.27.1424100209454; Mon, 16 Feb 2015 07:23:29 -0800 (PST) Received: by 10.141.3.214 with HTTP; Mon, 16 Feb 2015 07:23:29 -0800 (PST) X-Originating-IP: [114.164.140.7] Date: Mon, 16 Feb 2015 10:23:29 -0500 Message-ID: Subject: libssh2 in Javascript From: Nava Whiteford To: libssh2-devel@cool.haxx.se X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.18 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: multipart/mixed; boundary="===============1939607572==" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" --===============1939607572== Content-Type: multipart/alternative; boundary=001a11423b261c21c1050f362bfb --001a11423b261c21c1050f362bfb Content-Type: text/plain; charset=UTF-8 Hi all, Over the past few weeks I've been playing with libssh2 and Emscripten in order to port libssh2 to Javascript. I don't know if this has been done before, but it was an interesting project for me. I've released a proof of concept web based ssh client here: www.minaterm.com I'd recommend the "Eliza" demo to get an idea of how well it works, other connections are routed over Tor. The code is also available in github: http://github.com/new299/jterm Though I'm sure it's quite cringe-worthy. However I wanted to push it out and see if anyone else is interested in it before devoting further time to the project. Comments most welcome off-list (or if appropriate on-list). Thanks, Nava --001a11423b261c21c1050f362bfb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

Over th= e past few weeks I've been playing with libssh2 and Emscripten in order= to port libssh2 to Javascript. I don't know if this has been done befo= re, but it was an interesting project for me. I've released a proof of = concept web based ssh client here:

www.minaterm.com

I'd recommend the "Eliza"= ; demo to get an idea of how well it works, other connections are routed ov= er Tor. The code is also available in github:

http://github.com/new299/jterm

= Though I'm sure it's quite cringe-worthy. However I wanted to push = it out and see if anyone else is interested in it before devoting further t= ime to the project.

Comments most welcome off-list (or if appr= opriate on-list).

Thanks,

Nava
--001a11423b261c21c1050f362bfb-- --===============1939607572== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlic3NoMi1k ZXZlbCBodHRwOi8vY29vbC5oYXh4LnNlL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9saWJzc2gy LWRldmVsCg== --===============1939607572==-- From libssh2-devel-bounces@cool.haxx.se Tue Feb 17 05:34:14 2015 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-7) with ESMTP id t1H4XjTh004685; Tue, 17 Feb 2015 05:34:08 +0100 Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) by giant.haxx.se (8.14.4/8.14.4/Debian-7) with ESMTP id t1H4Xf5v004623 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 17 Feb 2015 05:33:42 +0100 Received: by iebtr6 with SMTP id tr6so27829669ieb.7 for ; Mon, 16 Feb 2015 20:33:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=jW1Um1j6NF+5CuN8TK5TjmifkLxJYY5PibDIgbFjMhk=; b=QdHZx0Cv2qy3evVgiWiT7lkWQAwwk3Ssop+sAoBgh32QGS3nE31oWT+jK3K0DtzgHi /sQKvoX8XehAQ0KmUB/zIRqEV7Bz09ohNHuERANY1hxzL2YxE1QGCIu1nGu9QgmyHP8o H0PyAyA1JP5JZPC1HOtJacc+soYnVVgQqnugiwDFIJYKWDxrBEYHlWp+Jg6OlGJpRu3s BNa0hKIv7Kwf7sf74fxBT6QL1pgERxdDwpo5JOWN2m5q7vF1iSxQ/fq+SD73iYrD+jh9 2Gz7jjwk2M30s1qoY451UAR7Sw228kxq/0zzbq0sSNreCHcB3C4TZTTBWln3iP0NQemm Piag== MIME-Version: 1.0 X-Received: by 10.107.152.211 with SMTP id a202mr20647124ioe.59.1424145720992; Mon, 16 Feb 2015 20:02:00 -0800 (PST) Received: by 10.36.87.21 with HTTP; Mon, 16 Feb 2015 20:02:00 -0800 (PST) In-Reply-To: References: Date: Mon, 16 Feb 2015 23:02:00 -0500 Message-ID: Subject: Re: libssh2 in Javascript From: Toan Pham To: libssh2 development X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.18 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: multipart/mixed; boundary="===============1627657449==" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" --===============1627657449== Content-Type: multipart/alternative; boundary=001a1140f538cf0c30050f40c304 --001a1140f538cf0c30050f40c304 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Nava, I am interested b/c I've written a similar web-based vt100 client side and a server side json rest service. It is working like a remote terminal; but the communication channel is not encrypted since it is using unencrypted json query back and forth. I would like to convert the multi-tier application to use html5 websock and openssl encryption in javascript; only then it would be highly efficient and secure. Sure, I will have a need for it, but do not have the time to contribute presently. thanks, TP =E2=80=8B --001a1140f538cf0c30050f40c304 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Nava,

I am inte= rested b/c I've written a similar web-based vt100 client side and a ser= ver side json rest service.=C2=A0 It is working like a remote terminal; but= the communication channel is=C2=A0 not encrypted since it is using unencry= pted json query back and forth.=C2=A0 I would like to convert the multi-tie= r application to use html5 websock and openssl encryption in javascript; on= ly then it would be highly efficient and secure.=C2=A0 Sure,=C2=A0 I will h= ave a need for it, but do not have the time to contribute presently.

thanks,

TP
=E2=80=8B
--001a1140f538cf0c30050f40c304-- --===============1627657449== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlic3NoMi1k ZXZlbCBodHRwOi8vY29vbC5oYXh4LnNlL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9saWJzc2gy LWRldmVsCg== --===============1627657449==-- From libssh2-devel-bounces@cool.haxx.se Tue Feb 17 07:30:16 2015 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-7) with ESMTP id t1H6U1H5027085; Tue, 17 Feb 2015 07:30:14 +0100 Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) by giant.haxx.se (8.14.4/8.14.4/Debian-7) with ESMTP id t1H6TwRb027023 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 17 Feb 2015 07:29:59 +0100 Received: by labhz20 with SMTP id hz20so33720349lab.0 for ; Mon, 16 Feb 2015 22:29:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Lvr++SB1ND+LDqGpsSkxyFd6Cyr9IahjA1PrMITmIpg=; b=uurZdvqlONKK6+saf3Z9xDwg9BVGLuSMirDZiS0k3yXmpTiqUCMcFPMoqwmjXVdHZF Yl9aP3HtMxsWH3tmqBaDQDb1JDgOUIf4i5AQN9F3NbENDXPbnVALM9ZwZ7xFJAUgD2IF OvLDXhViSvf4iaHAdYQWXyC02oLGP/+OK74LDp6tdFkRmolX2B2hvlOi5UZI9Awsl+13 mqVP3xTf2dzM5nHqNQj1s3Ze/qx3Idvcs94vQ0UN1UqdSskBhsg78qPg010l7Y0gqbmO kdKm/JQTzeNazm+gd5ugIu5aCp5Z3VOsg/hR5id7r3WxD9rf0Aba57XifEbEKTkTptqf t3Qg== MIME-Version: 1.0 X-Received: by 10.152.87.3 with SMTP id t3mr25327918laz.19.1424154594155; Mon, 16 Feb 2015 22:29:54 -0800 (PST) Received: by 10.112.149.106 with HTTP; Mon, 16 Feb 2015 22:29:54 -0800 (PST) Date: Tue, 17 Feb 2015 00:29:54 -0600 Message-ID: Subject: LIBSSH2 random crash in openssl library From: Srikanth Bemineni To: libssh2-devel@cool.haxx.se X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.18 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: multipart/mixed; boundary="===============0769633853==" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" --===============0769633853== Content-Type: multipart/alternative; boundary=001a11c35576b0a25c050f42d405 --001a11c35576b0a25c050f42d405 Content-Type: text/plain; charset=UTF-8 Hi, We are seeing this random crash in libssh2 while copying files in a multi threaded application. Our application is threaded application, and each file transfer happens in its own thread. Each thread creates its own libssh2 session and a channel to transfer the file. Occasionally we see this random crash in openssl library. Below is the stack trace of the crash. some_application.exe!sha1_block_data_order() + 0x2b5c bytes some_application.exe!SHA1_Update(SHAstate_st * c, const void * data_, unsigned __int64 len) Line 326 C some_application.exe!update(env_md_ctx_st * ctx, const void * data, unsigned __int64 count) Line 78 + 0x34 bytes C some_application.exe!EVP_DigestUpdate(env_md_ctx_st * ctx, const void * data, unsigned __int64 count) Line 252 C some_application.exe!ssleay_rand_bytes(unsigned char * buf, int num, int pseudo, int lock) Line 499 C some_application.exe!ssleay_rand_nopseudo_bytes(unsigned char * buf, int num) Line 542 C some_application.exe!RAND_bytes(unsigned char * buf, int num) Line 165 + 0x11 bytes C some_application.exe!_libssh2_transport_send(_LIBSSH2_SESSION * session, const unsigned char * data, unsigned __int64 data_len, const unsigned char * data2, unsigned __int64 data2_len) Line 820 C some_application.exe!_libssh2_channel_write(_LIBSSH2_CHANNEL * channel, int stream_id, const unsigned char * buf, unsigned __int64 buflen) Line 2060 + 0x46 bytes C some_application.exe!libssh2_channel_write_ex(_LIBSSH2_CHANNEL * channel, int stream_id, const char * buf, unsigned __int64 buflen) Line 2109 + 0x24 bytes C some_application.exe!Ssha::scp_write_file(QString * local_path, _LIBSSH2_CHANNEL * channel_new) Line 761 + 0x1b bytes C++ > some_application.exe!Ssha::PutFile(QString * local_path, QString * remote_path) Line 854 + 0x4a bytes C++ When I look at the session errmsg Its says "Unable to send channel data" with errcode LIBSSH2_ERROR_EAGAIN The locking mechanism is also in place for open ssl. We did check that openssl global data is locked and released by the mutex. Is there anything that we are missing from the libssh2 perspective ? init() { libssh2_init(0); CRYPTO_malloc_init(); CRYPTO_thread_setup() } shutDownSequence() { libssh2_exit(); CRYPTO_thread_cleanup(); } void locking_function(int mode, int n, const char *file, int line) { if (mode & CRYPTO_LOCK) { if(mutex_buf[n] != NULL) { mutex_buf[n]->lock(); } } else { if(mutex_buf[n] != NULL) { mutex_buf[n]->unlock(); } } } unsigned long id_function() { return (unsigned long)QThread::currentThreadId(); } void Cb_function(CRYPTO_THREADID *id) { CRYPTO_THREADID_set_numeric(id, (unsigned long)QThread::currentThreadId()); } bool CRYPTO_thread_setup() { int i; int num = CRYPTO_num_locks(); for (i = 0; i < num; i++) { lock_count[i] = 0; mutex_buf[i] = new QMutex(QMutex::NonRecursive); } CRYPTO_set_id_callback(id_function); CRYPTO_THREADID_set_callback(Cb_function); CRYPTO_set_locking_callback(locking_function); CRYPTO_set_dynlock_create_callback(dyn_create_function); CRYPTO_set_dynlock_lock_callback(dyn_lock_function); CRYPTO_set_dynlock_destroy_callback(dyn_destroy_function); return true; } void CRYPTO_thread_cleanup() { int i; int num = CRYPTO_num_locks(); if(crypto_initialized != 0) { CRYPTO_set_id_callback(NULL); CRYPTO_THREADID_set_callback(NULL); CRYPTO_set_locking_callback(NULL); CRYPTO_set_dynlock_create_callback(NULL); CRYPTO_set_dynlock_lock_callback(NULL); CRYPTO_set_dynlock_destroy_callback(NULL); for (i = 0; i < num; i++) { if(mutex_buf[i]) delete(mutex_buf[i]); } crypto_initialized = 0; } } I see a similar issue reported as a bug in http://trac.libssh2.org/ticket/212 . The resolution says adding libssh2_init(0); fixed the issue. This has already been taken care in our code, but we still see the crash. Srikanth Bemineni --001a11c35576b0a25c050f42d405 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

We are seeing this random crash in libssh2 while copying files in= a multi threaded application. Our application is threaded application, and= each file transfer happens in its own thread. Each thread creates its own = libssh2 session and a channel to transfer the file. Occasionally we see thi= s random crash in openssl library. Below is the stack trace of the crash.



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 some_application.exe!sha1_= block_data_order()=C2=A0 + 0x2b5c bytes=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 some_application.exe!SHA1_Update(SHAstate_st * c, const void * da= ta_, unsigned __int64 len)=C2=A0 Line 326=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 C
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 some_application.exe!update(env_md_ctx_st * ctx, c= onst void * data, unsigned __int64 count)=C2=A0 Line 78 + 0x34 bytes=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 C
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 some_application.exe!EVP_DigestUpda= te(env_md_ctx_st * ctx, const void * data, unsigned __int64 count)=C2=A0 Li= ne 252=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 C
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 some_application.exe!ssleay_rand_bytes(unsig= ned char * buf, int num, int pseudo, int lock)=C2=A0 Line 499=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 C
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 some_application.exe!ssleay_rand_nopseudo_bytes(unsigned= char * buf, int num)=C2=A0 Line 542=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 C
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 some_application.exe!RAND_bytes(= unsigned char * buf, int num)=C2=A0 Line 165 + 0x11 bytes=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 C
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 some_application.exe!_libssh2_transport_send(_L= IBSSH2_SESSION * session, const unsigned char * data, unsigned __int64 data= _len, const unsigned char * data2, unsigned __int64 data2_len)=C2=A0 Line 8= 20=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = C
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 some_application.exe!_libssh2_channel_write(_LIBSSH2_CHANNE= L * channel, int stream_id, const unsigned char * buf, unsigned __int64 buf= len)=C2=A0 Line 2060 + 0x46 bytes=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 C
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 some_application.= exe!libssh2_channel_write_ex(_LIBSSH2_CHANNEL * channel, int stream_id, con= st char * buf, unsigned __int64 buflen)=C2=A0 Line 2109 + 0x24 bytes=C2=A0= =C2=A0 C
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 some_application.exe!Ssha::scp_write_file(QString * l= ocal_path, _LIBSSH2_CHANNEL * channel_new)=C2=A0 Line 761 + 0x1b bytes=C2= =A0=C2=A0 C++
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 some_application.exe!Ssha::PutFile(QString * local= _path, QString * remote_path)=C2=A0 Line 854 + 0x4a bytes=C2=A0=C2=A0=C2=A0= =C2=A0 C++


When I look at the sessio= n errmsg=C2=A0 Its says "Unable to send channel data" with errcod= e LIBSSH2_ERROR_EAGAIN

The locking mechanism is also in place for open ssl. We did check that op= enssl global data is locked and released by the mutex. Is there anything th= at we are missing from the=C2=A0 libssh2 perspective ?

init()=
{
=C2=A0=C2=A0=C2=A0 libssh2_init(0);
=C2=A0=C2=A0=C2=A0 CRYPTO_m= alloc_init();
=C2=A0=C2=A0=C2=A0 CRYPTO_thread_setup()
}

shutDownSequence()
{
=C2=A0=C2=A0=C2=A0 libssh2_exit();
=C2= =A0=C2=A0=C2=A0 CRYPTO_thread_cleanup();
}

void lockin= g_function(int mode, int n, const char *file, int line)
{
=C2=A0=C2= =A0=C2=A0 if (mode & CRYPTO_LOCK)
=C2=A0=C2=A0=C2=A0 {
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if(mutex_buf[n] !=3D NULL)
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 mutex_buf[n]->lock();
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 }
=C2=A0=C2=A0=C2=A0 }
=C2=A0=C2=A0=C2=A0= else
=C2=A0=C2=A0=C2=A0 {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= if(mutex_buf[n] !=3D NULL)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 mute= x_buf[n]->unlock();
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
= =C2=A0=C2=A0=C2=A0 }
}

unsigned long id_function()
{
=C2= =A0=C2=A0=C2=A0 return (unsigned long)QThread::currentThreadId();
}
<= br>void Cb_function(CRYPTO_THREADID *id)
{
=C2=A0 CRYPTO_THREADID_set= _numeric(id, (unsigned long)QThread::currentThreadId());
}

bool C= RYPTO_thread_setup()
{
=C2=A0 int i;
=C2=A0 int num =3D CRYPTO_nu= m_locks();
=C2=A0=C2=A0=C2=A0 for (i =3D 0; i < num; i++)
=C2=A0= =C2=A0=C2=A0 {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 lock_count[i] =3D 0;
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 mutex_buf[i] =3D new QMutex(QMutex::NonRecur= sive);
=C2=A0=C2=A0=C2=A0 }
=C2=A0=C2=A0=C2=A0 CRYPTO_set_id_callback= (id_function);
=C2=A0=C2=A0=C2=A0 CRYPTO_THREADID_set_callback(Cb_functi= on);
=C2=A0=C2=A0=C2=A0 CRYPTO_set_locking_callback(locking_function);=C2=A0=C2=A0=C2=A0 CRYPTO_set_dynlock_create_callback(dyn_create_function= );
=C2=A0=C2=A0=C2=A0 CRYPTO_set_dynlock_lock_callback(dyn_lock_function= );
=C2=A0=C2=A0=C2=A0 CRYPTO_set_dynlock_destroy_callback(dyn_destroy_fu= nction);=C2=A0=C2=A0=C2=A0
=C2=A0 return true;
}

void CRYPTO_= thread_cleanup()
{
=C2=A0 int i;
=C2=A0 int num =3D CRYPTO_num_lo= cks();
=C2=A0 if(crypto_initialized !=3D 0)
=C2=A0 {
=C2=A0=C2= =A0=C2=A0 CRYPTO_set_id_callback(NULL);
=C2=A0=C2=A0=C2=A0 CRYPTO_THREAD= ID_set_callback(NULL);
=C2=A0=C2=A0=C2=A0 CRYPTO_set_locking_callback(NU= LL);
=C2=A0=C2=A0=C2=A0 CRYPTO_set_dynlock_create_callback(NULL);
=C2= =A0=C2=A0=C2=A0 CRYPTO_set_dynlock_lock_callback(NULL);
=C2=A0=C2=A0=C2= =A0 CRYPTO_set_dynlock_destroy_callback(NULL);
=C2=A0=C2=A0=C2=A0 for (i= =3D 0; i < num; i++)
=C2=A0=C2=A0=C2=A0 {
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 if(mutex_buf[i])
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 de= lete(mutex_buf[i]);
=C2=A0=C2=A0=C2=A0 }
=C2=A0=C2=A0=C2=A0 crypto_in= itialized =3D 0;
=C2=A0 }
}


=
I see a similar issue reported as a bug in http://trac.libssh2.org/ticket/212= =C2=A0 . The resolution says adding libssh2_init(0); fixed the issue. This = has already been taken care in our code, but we still see the crash.=

Srikanth Bemineni
--001a11c35576b0a25c050f42d405-- --===============0769633853== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlic3NoMi1k ZXZlbCBodHRwOi8vY29vbC5oYXh4LnNlL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9saWJzc2gy LWRldmVsCg== --===============0769633853==-- From libssh2-devel-bounces@cool.haxx.se Tue Feb 17 19:22:10 2015 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-7) with ESMTP id t1HILbw2007806; Tue, 17 Feb 2015 19:22:04 +0100 Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) by giant.haxx.se (8.14.4/8.14.4/Debian-7) with ESMTP id t1HILamv007770 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 17 Feb 2015 19:21:36 +0100 Received: by lams18 with SMTP id s18so37492234lam.11 for ; Tue, 17 Feb 2015 10:21:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=WgK2WHVpvxpjERVPu08Lx/xmAqxNBsbIJq9C7/yK26s=; b=vUj6zq6S++d2yb2raohMpzfU306k/o9fd+wx6BvzR5eoA7p9tzgpJf1NTu8BAoWqSc abF1GeiEoaL2gcMcwp+CzNFsunfv2Qt5rVWnHUY5DjGKpPSaG5pv11D4OpcDOSwcSntq weKPMqW8HT8YMh7JUiCpda1+p7jRFCX8kF0sTtJc7xctWklmfAoFNINE27XVUKQZlNf6 KVgQyRiPp9tlEPm7eEBU16hbLMmDvsN9YtgeWQbxdfkH94JVdqf23gkdz1iNqjkesF7O LNP5d5JO1BJh44tpDROXYWg+FzJFTRDlBpegxc6JaOaUgXSogqpyjXYxFWB7HRijwFtf wVjA== MIME-Version: 1.0 X-Received: by 10.112.185.101 with SMTP id fb5mr30802438lbc.12.1424197292254; Tue, 17 Feb 2015 10:21:32 -0800 (PST) Received: by 10.112.149.106 with HTTP; Tue, 17 Feb 2015 10:21:32 -0800 (PST) In-Reply-To: References: Date: Tue, 17 Feb 2015 12:21:32 -0600 Message-ID: Subject: Re: LIBSSH2 random crash in openssl library From: Srikanth Bemineni To: libssh2-devel@cool.haxx.se X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.18 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: multipart/mixed; boundary="===============1675002787==" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" --===============1675002787== Content-Type: multipart/alternative; boundary=001a11c3c516b1e9d3050f4cc5dc --001a11c3c516b1e9d3050f4cc5dc Content-Type: text/plain; charset=UTF-8 Hi, Some more details on the issue that I found out in the openssl bug list archive #1764: openssl-0.9.8i random generator - bug http://rt.openssl.org/Ticket/Display.html?id=1764#2630: Segmentation-fault in ssleay_rand_bytes() after generating a large (INT_MAX) random buffer http://rt.openssl.org/Ticket/Display.html?id=2630&user=guest&pass=guest Srikanth Bemineni On Tue, Feb 17, 2015 at 12:29 AM, Srikanth Bemineni < bemineni.srikanth@gmail.com> wrote: > Hi, > > We are seeing this random crash in libssh2 while copying files in a multi > threaded application. Our application is threaded application, and each > file transfer happens in its own thread. Each thread creates its own > libssh2 session and a channel to transfer the file. Occasionally we see > this random crash in openssl library. Below is the stack trace of the crash. > > > > some_application.exe!sha1_block_data_order() + 0x2b5c > bytes > some_application.exe!SHA1_Update(SHAstate_st * c, const > void * data_, unsigned __int64 len) Line 326 C > some_application.exe!update(env_md_ctx_st * ctx, const void > * data, unsigned __int64 count) Line 78 + 0x34 bytes C > some_application.exe!EVP_DigestUpdate(env_md_ctx_st * ctx, > const void * data, unsigned __int64 count) Line 252 C > some_application.exe!ssleay_rand_bytes(unsigned char * buf, > int num, int pseudo, int lock) Line 499 C > some_application.exe!ssleay_rand_nopseudo_bytes(unsigned > char * buf, int num) Line 542 C > some_application.exe!RAND_bytes(unsigned char * buf, int > num) Line 165 + 0x11 bytes C > > some_application.exe!_libssh2_transport_send(_LIBSSH2_SESSION * session, > const unsigned char * data, unsigned __int64 data_len, const unsigned char > * data2, unsigned __int64 data2_len) Line 820 C > > some_application.exe!_libssh2_channel_write(_LIBSSH2_CHANNEL * channel, int > stream_id, const unsigned char * buf, unsigned __int64 buflen) Line 2060 + > 0x46 bytes C > > some_application.exe!libssh2_channel_write_ex(_LIBSSH2_CHANNEL * channel, > int stream_id, const char * buf, unsigned __int64 buflen) Line 2109 + 0x24 > bytes C > some_application.exe!Ssha::scp_write_file(QString * > local_path, _LIBSSH2_CHANNEL * channel_new) Line 761 + 0x1b bytes C++ > > some_application.exe!Ssha::PutFile(QString * local_path, > QString * remote_path) Line 854 + 0x4a bytes C++ > > > When I look at the session errmsg Its says "Unable to send channel data" > with errcode LIBSSH2_ERROR_EAGAIN > > The locking mechanism is also in place for open ssl. We did check that > openssl global data is locked and released by the mutex. Is there anything > that we are missing from the libssh2 perspective ? > > init() > { > libssh2_init(0); > CRYPTO_malloc_init(); > CRYPTO_thread_setup() > } > > shutDownSequence() > { > libssh2_exit(); > CRYPTO_thread_cleanup(); > } > > void locking_function(int mode, int n, const char *file, int line) > { > if (mode & CRYPTO_LOCK) > { > if(mutex_buf[n] != NULL) > { > mutex_buf[n]->lock(); > } > } > else > { > if(mutex_buf[n] != NULL) > { > mutex_buf[n]->unlock(); > } > } > } > > unsigned long id_function() > { > return (unsigned long)QThread::currentThreadId(); > } > > void Cb_function(CRYPTO_THREADID *id) > { > CRYPTO_THREADID_set_numeric(id, (unsigned > long)QThread::currentThreadId()); > } > > bool CRYPTO_thread_setup() > { > int i; > int num = CRYPTO_num_locks(); > for (i = 0; i < num; i++) > { > lock_count[i] = 0; > mutex_buf[i] = new QMutex(QMutex::NonRecursive); > } > CRYPTO_set_id_callback(id_function); > CRYPTO_THREADID_set_callback(Cb_function); > CRYPTO_set_locking_callback(locking_function); > CRYPTO_set_dynlock_create_callback(dyn_create_function); > CRYPTO_set_dynlock_lock_callback(dyn_lock_function); > CRYPTO_set_dynlock_destroy_callback(dyn_destroy_function); > return true; > } > > void CRYPTO_thread_cleanup() > { > int i; > int num = CRYPTO_num_locks(); > if(crypto_initialized != 0) > { > CRYPTO_set_id_callback(NULL); > CRYPTO_THREADID_set_callback(NULL); > CRYPTO_set_locking_callback(NULL); > CRYPTO_set_dynlock_create_callback(NULL); > CRYPTO_set_dynlock_lock_callback(NULL); > CRYPTO_set_dynlock_destroy_callback(NULL); > for (i = 0; i < num; i++) > { > if(mutex_buf[i]) > delete(mutex_buf[i]); > } > crypto_initialized = 0; > } > } > > > I see a similar issue reported as a bug in > http://trac.libssh2.org/ticket/212 . The resolution says adding > libssh2_init(0); fixed the issue. This has already been taken care in our > code, but we still see the crash. > > Srikanth Bemineni > --001a11c3c516b1e9d3050f4cc5dc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Some more details on the issue that = I found out in the openssl bug list archive

#1764: openssl-0.9.8= i random generator - bug http://rt.openssl.org/Ticket/Display.html?id=3D1764

<= h1>#2630: Segmentation-fault in ssleay_rand_bytes() after generating a larg= e (INT_MAX) random buffer

http://rt.open= ssl.org/Ticket/Display.html?id=3D2630&user=3Dguest&pass=3Dguest=


Srikanth Bemineni



On Tue, Feb 17, 2015 at 12:29 AM, Srika= nth Bemineni <bemineni.srikanth@gmail.com> wrote:<= br>
Hi,

We are seeing this random crash= in libssh2 while copying files in a multi threaded application. Our applic= ation is threaded application, and each file transfer happens in its own th= read. Each thread creates its own libssh2 session and a channel to transfer= the file. Occasionally we see this random crash in openssl library. Below = is the stack trace of the crash.



=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 some_application.exe!sha1_block_data_order()=C2=A0 + 0x2b5c bytes=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 some_application.exe!SHA1_Update= (SHAstate_st * c, const void * data_, unsigned __int64 len)=C2=A0 Line 326= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 C
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 some_application.= exe!update(env_md_ctx_st * ctx, const void * data, unsigned __int64 count)= =C2=A0 Line 78 + 0x34 bytes=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 C
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 so= me_application.exe!EVP_DigestUpdate(env_md_ctx_st * ctx, const void * data,= unsigned __int64 count)=C2=A0 Line 252=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 C
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 some_applic= ation.exe!ssleay_rand_bytes(unsigned char * buf, int num, int pseudo, int l= ock)=C2=A0 Line 499=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 C
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 some_application.exe!ss= leay_rand_nopseudo_bytes(unsigned char * buf, int num)=C2=A0 Line 542=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 C
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= some_application.exe!RAND_bytes(unsigned char * buf, int num)=C2=A0 Line 1= 65 + 0x11 bytes=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 C
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 some_applicati= on.exe!_libssh2_transport_send(_LIBSSH2_SESSION * session, const unsigned c= har * data, unsigned __int64 data_len, const unsigned char * data2, unsigne= d __int64 data2_len)=C2=A0 Line 820=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 C
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 some_application.exe!_libs= sh2_channel_write(_LIBSSH2_CHANNEL * channel, int stream_id, const unsigned= char * buf, unsigned __int64 buflen)=C2=A0 Line 2060 + 0x46 bytes=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= C
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 some_application.exe!libssh2_channel_write_ex(_LIBSSH2_CHAN= NEL * channel, int stream_id, const char * buf, unsigned __int64 buflen)=C2= =A0 Line 2109 + 0x24 bytes=C2=A0=C2=A0 C
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 some_application.exe= !Ssha::scp_write_file(QString * local_path, _LIBSSH2_CHANNEL * channel_new)= =C2=A0 Line 761 + 0x1b bytes=C2=A0=C2=A0 C++
>=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 some_application.= exe!Ssha::PutFile(QString * local_path, QString * remote_path)=C2=A0 Line 8= 54 + 0x4a bytes=C2=A0=C2=A0=C2=A0=C2=A0 C++


When I look at the session errmsg=C2=A0 Its says "Unable to se= nd channel data" with errcode LIBSSH2_ERROR_EAGAIN

The locking mechanism is also in place f= or open ssl. We did check that openssl global data is locked and released b= y the mutex. Is there anything that we are missing from the=C2=A0 libssh2 p= erspective ?

init()
{
=C2=A0=C2=A0=C2=A0 libssh2_init(0= );
=C2=A0=C2=A0=C2=A0 CRYPTO_malloc_init();
=C2=A0=C2=A0=C2=A0 CRYPTO= _thread_setup()
}

shutDownSequence()
{
=C2=A0=C2= =A0=C2=A0 libssh2_exit();
=C2=A0=C2=A0=C2=A0 CRYPTO_thread_cleanup();}

void locking_function(int mode, int n, const char *fil= e, int line)
{
=C2=A0=C2=A0=C2=A0 if (mode & CRYPTO_LOCK)
=C2= =A0=C2=A0=C2=A0 {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if(mutex_bu= f[n] !=3D NULL)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 mutex_buf[n]-&= gt;lock();
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
=C2=A0=C2=A0= =C2=A0 }
=C2=A0=C2=A0=C2=A0 else
=C2=A0=C2=A0=C2=A0 {
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if(mutex_buf[n] !=3D NULL)
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 mutex_buf[n]->unlock();
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 }
=C2=A0=C2=A0=C2=A0 }
}

unsigned = long id_function()
{
=C2=A0=C2=A0=C2=A0 return (unsigned long)QThrea= d::currentThreadId();
}

void Cb_function(CRYPTO_THREADID *id)
= {
=C2=A0 CRYPTO_THREADID_set_numeric(id, (unsigned long)QThread::current= ThreadId());
}

bool CRYPTO_thread_setup()
{
=C2=A0 int i;<= br>=C2=A0 int num =3D CRYPTO_num_locks();
=C2=A0=C2=A0=C2=A0 for (i =3D = 0; i < num; i++)
=C2=A0=C2=A0=C2=A0 {
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 lock_count[i] =3D 0;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 mutex_buf[i] =3D= new QMutex(QMutex::NonRecursive);
=C2=A0=C2=A0=C2=A0 }
=C2=A0=C2=A0= =C2=A0 CRYPTO_set_id_callback(id_function);
=C2=A0=C2=A0=C2=A0 CRYPTO_TH= READID_set_callback(Cb_function);
=C2=A0=C2=A0=C2=A0 CRYPTO_set_locking_= callback(locking_function);
=C2=A0=C2=A0=C2=A0 CRYPTO_set_dynlock_create= _callback(dyn_create_function);
=C2=A0=C2=A0=C2=A0 CRYPTO_set_dynlock_lo= ck_callback(dyn_lock_function);
=C2=A0=C2=A0=C2=A0 CRYPTO_set_dynlock_de= stroy_callback(dyn_destroy_function);=C2=A0=C2=A0=C2=A0
=C2=A0 return t= rue;
}

void CRYPTO_thread_cleanup()
{
=C2=A0 int i;
=C2= =A0 int num =3D CRYPTO_num_locks();
=C2=A0 if(crypto_initialized !=3D 0)=
=C2=A0 {
=C2=A0=C2=A0=C2=A0 CRYPTO_set_id_callback(NULL);
=C2= =A0=C2=A0=C2=A0 CRYPTO_THREADID_set_callback(NULL);
=C2=A0=C2=A0=C2=A0 C= RYPTO_set_locking_callback(NULL);
=C2=A0=C2=A0=C2=A0 CRYPTO_set_dynlock_= create_callback(NULL);
=C2=A0=C2=A0=C2=A0 CRYPTO_set_dynlock_lock_callba= ck(NULL);
=C2=A0=C2=A0=C2=A0 CRYPTO_set_dynlock_destroy_callback(NULL);<= br>=C2=A0=C2=A0=C2=A0 for (i =3D 0; i < num; i++)
=C2=A0=C2=A0=C2=A0 = {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if(mutex_buf[i])
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 delete(mutex_buf[i]);
=C2=A0=C2=A0=C2=A0 }
= =C2=A0=C2=A0=C2=A0 crypto_initialized =3D 0;
=C2=A0 }
}


I see a similar issue rep= orted as a bug in http://trac.libssh2.org/ticket/212=C2=A0 . The resolution says = adding libssh2_init(0); fixed the issue. This has already been taken care i= n our code, but we still see the crash.

Srikanth Bemineni
<= /font>

--001a11c3c516b1e9d3050f4cc5dc-- --===============1675002787== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlic3NoMi1k ZXZlbCBodHRwOi8vY29vbC5oYXh4LnNlL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9saWJzc2gy LWRldmVsCg== --===============1675002787==-- From libssh2-devel-bounces@cool.haxx.se Fri Feb 20 17:18:40 2015 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-7) with ESMTP id t1KGIDu0012189; Fri, 20 Feb 2015 17:18:35 +0100 Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by giant.haxx.se (8.14.4/8.14.4/Debian-7) with ESMTP id t1KGICi4012039 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Fri, 20 Feb 2015 17:18:12 +0100 Received: by lams18 with SMTP id s18so7072547lam.11 for ; Fri, 20 Feb 2015 08:18:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=gcUbJ9P1ERnpMNItaxh7i3iO6U3VaECpAT7eCBU2TDs=; b=hsu7dVrtGt/gD0fY6InoTxSnBZjAo6CV4bQVOFx/3ZCAzG4bUoPW/BSFsMJEBcwMq8 wEUDY39QwS/8p56PXtBW/wjTqk4hlU2dNJvdD4/IVq+RG7vjVXI9fmYO3rWMVG+O2fOQ 9r7wnLoeaZA7Q5W/MMLAzD0hPJ4cLYgrt6k/RB49I9ClYpB4fhaJK1xRDkjzxN9qZ9HW GEL/6ddyUVzxIJdRqJUogSgoXW3fOuuR3+YBU+pP+AfX27q2ZkMxNBLvADlny5q5m0+q abAdbMr8UGzdMJFcwdivAtsVHV6YcVnr8KMY+Kna71w5kKxGNT3rr3RPg606bXSU46Nf PLEQ== MIME-Version: 1.0 X-Received: by 10.152.25.132 with SMTP id c4mr9190283lag.101.1424449087923; Fri, 20 Feb 2015 08:18:07 -0800 (PST) Received: by 10.112.149.106 with HTTP; Fri, 20 Feb 2015 08:18:07 -0800 (PST) In-Reply-To: References: Date: Fri, 20 Feb 2015 10:18:07 -0600 Message-ID: Subject: Re: LIBSSH2 random crash in openssl library From: Srikanth Bemineni To: libssh2-devel@cool.haxx.se X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.18 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: multipart/mixed; boundary="===============1764164816==" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" --===============1764164816== Content-Type: multipart/alternative; boundary=089e0160b9b0e2ecfc050f876581 --089e0160b9b0e2ecfc050f876581 Content-Type: text/plain; charset=UTF-8 Hi, I have gone through many suggestion most of them ask us to check the locking mechanism. Following the suggestion, I was able to find the issue.. Many people who have faced this issue, after resolving the issue have not updated the reason. I am just explaining my scenario here, and how it was resolved. My application uses openssl with many other opensource third party libraries, like a open source web server mongoose, libssh2, gsoap, libcurl and also open pegasus. In all the mentioned libraries most of the documentation recommends the application to maintain the openssl thread callbacks, except for two libraries mongoose and Open pegasus. Both of these libraries register and de-register openssl thread call backs when needed. This used to cause thread locking set by the application to be reset. This resulted in openssl data structure's to get corrupted for other openssl calls from libssh2, gsoap and libcurl to get corrupted. I have also reported the same as a bug on Open Pegasus project. My suggestion when you face this issue, assuming everything is fine from your application, Please check the third party library for the openssl callback registration function CRYPTO_set_locking_callback() Srikanth Bemineni On Tue, Feb 17, 2015 at 12:21 PM, Srikanth Bemineni < bemineni.srikanth@gmail.com> wrote: > Hi, > > Some more details on the issue that I found out in the openssl bug list > archive > > #1764: openssl-0.9.8i random generator - bug > http://rt.openssl.org/Ticket/Display.html?id=1764#2630: > Segmentation-fault in ssleay_rand_bytes() after generating a large > (INT_MAX) random buffer > > http://rt.openssl.org/Ticket/Display.html?id=2630&user=guest&pass=guest > > > Srikanth Bemineni > > > On Tue, Feb 17, 2015 at 12:29 AM, Srikanth Bemineni < > bemineni.srikanth@gmail.com> wrote: > >> Hi, >> >> We are seeing this random crash in libssh2 while copying files in a multi >> threaded application. Our application is threaded application, and each >> file transfer happens in its own thread. Each thread creates its own >> libssh2 session and a channel to transfer the file. Occasionally we see >> this random crash in openssl library. Below is the stack trace of the crash. >> >> >> >> some_application.exe!sha1_block_data_order() + 0x2b5c >> bytes >> some_application.exe!SHA1_Update(SHAstate_st * c, const >> void * data_, unsigned __int64 len) Line 326 C >> some_application.exe!update(env_md_ctx_st * ctx, const >> void * data, unsigned __int64 count) Line 78 + 0x34 bytes C >> some_application.exe!EVP_DigestUpdate(env_md_ctx_st * ctx, >> const void * data, unsigned __int64 count) Line 252 C >> some_application.exe!ssleay_rand_bytes(unsigned char * >> buf, int num, int pseudo, int lock) Line 499 C >> some_application.exe!ssleay_rand_nopseudo_bytes(unsigned >> char * buf, int num) Line 542 C >> some_application.exe!RAND_bytes(unsigned char * buf, int >> num) Line 165 + 0x11 bytes C >> >> some_application.exe!_libssh2_transport_send(_LIBSSH2_SESSION * session, >> const unsigned char * data, unsigned __int64 data_len, const unsigned char >> * data2, unsigned __int64 data2_len) Line 820 C >> >> some_application.exe!_libssh2_channel_write(_LIBSSH2_CHANNEL * channel, int >> stream_id, const unsigned char * buf, unsigned __int64 buflen) Line 2060 + >> 0x46 bytes C >> >> some_application.exe!libssh2_channel_write_ex(_LIBSSH2_CHANNEL * channel, >> int stream_id, const char * buf, unsigned __int64 buflen) Line 2109 + 0x24 >> bytes C >> some_application.exe!Ssha::scp_write_file(QString * >> local_path, _LIBSSH2_CHANNEL * channel_new) Line 761 + 0x1b bytes C++ >> > some_application.exe!Ssha::PutFile(QString * local_path, >> QString * remote_path) Line 854 + 0x4a bytes C++ >> >> >> When I look at the session errmsg Its says "Unable to send channel data" >> with errcode LIBSSH2_ERROR_EAGAIN >> >> The locking mechanism is also in place for open ssl. We did check that >> openssl global data is locked and released by the mutex. Is there anything >> that we are missing from the libssh2 perspective ? >> >> init() >> { >> libssh2_init(0); >> CRYPTO_malloc_init(); >> CRYPTO_thread_setup() >> } >> >> shutDownSequence() >> { >> libssh2_exit(); >> CRYPTO_thread_cleanup(); >> } >> >> void locking_function(int mode, int n, const char *file, int line) >> { >> if (mode & CRYPTO_LOCK) >> { >> if(mutex_buf[n] != NULL) >> { >> mutex_buf[n]->lock(); >> } >> } >> else >> { >> if(mutex_buf[n] != NULL) >> { >> mutex_buf[n]->unlock(); >> } >> } >> } >> >> unsigned long id_function() >> { >> return (unsigned long)QThread::currentThreadId(); >> } >> >> void Cb_function(CRYPTO_THREADID *id) >> { >> CRYPTO_THREADID_set_numeric(id, (unsigned >> long)QThread::currentThreadId()); >> } >> >> bool CRYPTO_thread_setup() >> { >> int i; >> int num = CRYPTO_num_locks(); >> for (i = 0; i < num; i++) >> { >> lock_count[i] = 0; >> mutex_buf[i] = new QMutex(QMutex::NonRecursive); >> } >> CRYPTO_set_id_callback(id_function); >> CRYPTO_THREADID_set_callback(Cb_function); >> CRYPTO_set_locking_callback(locking_function); >> CRYPTO_set_dynlock_create_callback(dyn_create_function); >> CRYPTO_set_dynlock_lock_callback(dyn_lock_function); >> CRYPTO_set_dynlock_destroy_callback(dyn_destroy_function); >> return true; >> } >> >> void CRYPTO_thread_cleanup() >> { >> int i; >> int num = CRYPTO_num_locks(); >> if(crypto_initialized != 0) >> { >> CRYPTO_set_id_callback(NULL); >> CRYPTO_THREADID_set_callback(NULL); >> CRYPTO_set_locking_callback(NULL); >> CRYPTO_set_dynlock_create_callback(NULL); >> CRYPTO_set_dynlock_lock_callback(NULL); >> CRYPTO_set_dynlock_destroy_callback(NULL); >> for (i = 0; i < num; i++) >> { >> if(mutex_buf[i]) >> delete(mutex_buf[i]); >> } >> crypto_initialized = 0; >> } >> } >> >> >> I see a similar issue reported as a bug in >> http://trac.libssh2.org/ticket/212 . The resolution says adding >> libssh2_init(0); fixed the issue. This has already been taken care in our >> code, but we still see the crash. >> >> Srikanth Bemineni >> > > --089e0160b9b0e2ecfc050f876581 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I have gone through many suggestion= most of them ask us to check the locking mechanism. Following the suggesti= on, =C2=A0I was able to find the issue.. Many people who have faced this is= sue, after resolving the issue have not updated the reason. I am just expla= ining my scenario here, and how it was resolved.

<= br>
My application uses openssl with many other opensource third = party libraries, like a open source web server mongoose, libssh2, gsoap, li= bcurl and also open pegasus. In all the mentioned libraries most of the doc= umentation recommends the application to maintain the openssl thread callba= cks, except for two libraries mongoose and Open pegasus. Both of these libr= aries register and de-register openssl thread call backs when needed. This = used to cause thread locking set by the application to be reset. This resul= ted in openssl data structure's to get corrupted for other openssl call= s from libssh2, gsoap and libcurl to get corrupted.

I have also reported the same as a bug on Open Pegasus project.

My suggestion when you face this issue, assuming everything= is fine from your application, Please check the third party library for th= e openssl callback registration function=C2=A0CRYPTO_set_locking_callback()

Srikanth Bemineni

On Tue, Feb 17, 2015 at 12:21 = PM, Srikanth Bemineni <bemineni.srikanth@gmail.com> wrote:
Hi,
Some more details on the issue that I found out in the openssl bug l= ist archive

#1764: openssl-0.9.8i random generator - bug = http://rt.openssl.org/Ticket/Display.html?id=3D1764

#2630: Segm= entation-fault in ssleay_rand_bytes() after generating a large (INT_MAX) ra= ndom buffer

http://rt.= openssl.org/Ticket/Display.html?id=3D2630&user=3Dguest&pass=3Dguest=


Srikan= th Bemineni



On Tue, F= eb 17, 2015 at 12:29 AM, Srikanth Bemineni <bemineni.srikanth@gm= ail.com> wrote:
Hi,

W= e are seeing this random crash in libssh2 while copying files in a multi th= readed application. Our application is threaded application, and each file = transfer happens in its own thread. Each thread creates its own libssh2 ses= sion and a channel to transfer the file. Occasionally we see this random cr= ash in openssl library. Below is the stack trace of the crash.


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 some_application.exe!sha1_block_data_o= rder()=C2=A0 + 0x2b5c bytes=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 so= me_application.exe!SHA1_Update(SHAstate_st * c, const void * data_, unsigne= d __int64 len)=C2=A0 Line 326=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 C=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 some_application.exe!update(env_md_ctx_st * ctx, const void * = data, unsigned __int64 count)=C2=A0 Line 78 + 0x34 bytes=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 C
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 some_application.exe!EVP_DigestUpdate(env_md_ct= x_st * ctx, const void * data, unsigned __int64 count)=C2=A0 Line 252=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 C
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 some_application.exe!ssleay_rand_bytes(unsigned char * b= uf, int num, int pseudo, int lock)=C2=A0 Line 499=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 C
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 some_application.exe!ssleay_rand_nopseudo_bytes(unsigned char * buf,= int num)=C2=A0 Line 542=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 C
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 some_application.exe!RAND_bytes(unsigned cha= r * buf, int num)=C2=A0 Line 165 + 0x11 bytes=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= C
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 some_application.exe!_libssh2_transport_send(_LIBSSH2_SESSI= ON * session, const unsigned char * data, unsigned __int64 data_len, const = unsigned char * data2, unsigned __int64 data2_len)=C2=A0 Line 820=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 C
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 some_application.exe!_libssh2_channel_write(_LIBSSH2_CHANNEL * channel,= int stream_id, const unsigned char * buf, unsigned __int64 buflen)=C2=A0 L= ine 2060 + 0x46 bytes=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 C
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 some_application.exe!libssh2_= channel_write_ex(_LIBSSH2_CHANNEL * channel, int stream_id, const char * bu= f, unsigned __int64 buflen)=C2=A0 Line 2109 + 0x24 bytes=C2=A0=C2=A0 C
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 some_application.exe!Ssha::scp_write_file(QString * local_path, _= LIBSSH2_CHANNEL * channel_new)=C2=A0 Line 761 + 0x1b bytes=C2=A0=C2=A0 C++<= br>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 some_application.exe!Ssha::PutFile(QString * local_path, QStri= ng * remote_path)=C2=A0 Line 854 + 0x4a bytes=C2=A0=C2=A0=C2=A0=C2=A0 C++

When I look at the session errmsg=C2= =A0 Its says "Unable to send channel data" with errcode LIBSSH2_E= RROR_EAGAIN

The locki= ng mechanism is also in place for open ssl. We did check that openssl globa= l data is locked and released by the mutex. Is there anything that we are m= issing from the=C2=A0 libssh2 perspective ?

init()
{
= =C2=A0=C2=A0=C2=A0 libssh2_init(0);
=C2=A0=C2=A0=C2=A0 CRYPTO_malloc_ini= t();
=C2=A0=C2=A0=C2=A0 CRYPTO_thread_setup()
}

shu= tDownSequence()
{
=C2=A0=C2=A0=C2=A0 libssh2_exit();
=C2=A0=C2=A0= =C2=A0 CRYPTO_thread_cleanup();
}

void locking_functio= n(int mode, int n, const char *file, int line)
{
=C2=A0=C2=A0=C2=A0 = if (mode & CRYPTO_LOCK)
=C2=A0=C2=A0=C2=A0 {
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 if(mutex_buf[n] !=3D NULL)
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 mutex_buf[n]->lock();
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 }
=C2=A0=C2=A0=C2=A0 }
=C2=A0=C2=A0=C2=A0 else
= =C2=A0=C2=A0=C2=A0 {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if(mutex= _buf[n] !=3D NULL)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 mutex_buf[n= ]->unlock();
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
=C2=A0= =C2=A0=C2=A0 }
}

unsigned long id_function()
{
=C2=A0=C2= =A0=C2=A0 return (unsigned long)QThread::currentThreadId();
}

voi= d Cb_function(CRYPTO_THREADID *id)
{
=C2=A0 CRYPTO_THREADID_set_numer= ic(id, (unsigned long)QThread::currentThreadId());
}

bool CRYPTO_= thread_setup()
{
=C2=A0 int i;
=C2=A0 int num =3D CRYPTO_num_lock= s();
=C2=A0=C2=A0=C2=A0 for (i =3D 0; i < num; i++)
=C2=A0=C2=A0= =C2=A0 {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 lock_count[i] =3D 0;
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 mutex_buf[i] =3D new QMutex(QMutex::NonRecursive);=
=C2=A0=C2=A0=C2=A0 }
=C2=A0=C2=A0=C2=A0 CRYPTO_set_id_callback(id_fu= nction);
=C2=A0=C2=A0=C2=A0 CRYPTO_THREADID_set_callback(Cb_function);=C2=A0=C2=A0=C2=A0 CRYPTO_set_locking_callback(locking_function);
=C2= =A0=C2=A0=C2=A0 CRYPTO_set_dynlock_create_callback(dyn_create_function);=C2=A0=C2=A0=C2=A0 CRYPTO_set_dynlock_lock_callback(dyn_lock_function);=C2=A0=C2=A0=C2=A0 CRYPTO_set_dynlock_destroy_callback(dyn_destroy_functio= n);=C2=A0=C2=A0=C2=A0
=C2=A0 return true;
}

void CRYPTO_threa= d_cleanup()
{
=C2=A0 int i;
=C2=A0 int num =3D CRYPTO_num_locks()= ;
=C2=A0 if(crypto_initialized !=3D 0)
=C2=A0 {
=C2=A0=C2=A0=C2= =A0 CRYPTO_set_id_callback(NULL);
=C2=A0=C2=A0=C2=A0 CRYPTO_THREADID_set= _callback(NULL);
=C2=A0=C2=A0=C2=A0 CRYPTO_set_locking_callback(NULL);=C2=A0=C2=A0=C2=A0 CRYPTO_set_dynlock_create_callback(NULL);
=C2=A0=C2= =A0=C2=A0 CRYPTO_set_dynlock_lock_callback(NULL);
=C2=A0=C2=A0=C2=A0 CRY= PTO_set_dynlock_destroy_callback(NULL);
=C2=A0=C2=A0=C2=A0 for (i =3D 0;= i < num; i++)
=C2=A0=C2=A0=C2=A0 {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= if(mutex_buf[i])
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 delete(mute= x_buf[i]);
=C2=A0=C2=A0=C2=A0 }
=C2=A0=C2=A0=C2=A0 crypto_initialized= =3D 0;
=C2=A0 }
}


I see a similar issue reported as a bug in http://trac.libssh2.org/ticke= t/212=C2=A0 . The resolution says adding libssh2_init(0); fixed the iss= ue. This has already been taken care in our code, but we still see the cras= h.

Srikanth Bemineni


--089e0160b9b0e2ecfc050f876581-- --===============1764164816== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlic3NoMi1k ZXZlbCBodHRwOi8vY29vbC5oYXh4LnNlL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9saWJzc2gy LWRldmVsCg== --===============1764164816==-- From libssh2-devel-bounces@cool.haxx.se Sat Feb 21 23:48:49 2015 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-7) with ESMTP id t1LMmOGI002920; Sat, 21 Feb 2015 23:48:44 +0100 Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-7) with ESMTP id t1LMmMaR002903 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sat, 21 Feb 2015 23:48:22 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id t1LMmMwX002883 for ; Sat, 21 Feb 2015 23:48:22 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Sat, 21 Feb 2015 23:48:22 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: libssh2 development Subject: Ok, let's talk release again. For real. Message-ID: User-Agent: Alpine 2.11 (DEB 23 2013-08-11) X-fromdanielhimself: yes MIME-Version: 1.0 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.18 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id t1LMmOGI002920 Yeps, Do anyone have any stuff that should go in before a release? And then I mean something you yourself plan to fix within a week or so. -- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Tue Feb 24 21:35:08 2015 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-7) with ESMTP id t1OKYcMI032042; Tue, 24 Feb 2015 21:35:03 +0100 Received: from mx.uxnr.de (mx.uxnr.de [89.238.84.48]) by giant.haxx.se (8.14.4/8.14.4/Debian-7) with ESMTP id t1OKYbFg031885 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 24 Feb 2015 21:34:37 +0100 Received: from marcs-mbp.marc.uxnr.eu (marcs-mbp.marc.uxnr.eu [10.10.0.2]) by mx.uxnr.de (Postfix) with ESMTPSA id B12771C5A33A for ; Tue, 24 Feb 2015 21:34:44 +0100 (CET) X-DKIM: OpenDKIM Filter v2.6.8 mx.uxnr.de B12771C5A33A DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=marc-hoersken.de; s=picard; t=1424810085; bh=C8dyy4IEVc7MouQtZaX2vOa9zXsOxXPmhugWuMRTti8=; h=From:Subject:Date:References:To:In-Reply-To:From; b=Cgnkrf91ZM23DFZmkmCzInD5HkjYm5QQBrtA20JES/8uNlb8d0OUnqOaXIDUvNaq3 mqURtTuT/5cK3ornTvCM+zsgVfZs3ieEoNR+jS+gY6qeBbMaey8tYE7k2al1u24hCo RPBR3dvjyMCdvR2luK0cXJfcbvjdYwCPmj6qHCZE= From: =?utf-8?Q?Marc_H=C3=B6rsken?= Message-Id: Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: Ok, let's talk release again. For real. Date: Tue, 24 Feb 2015 21:34:23 +0100 References: To: libssh2 development In-Reply-To: X-Mailer: Apple Mail (2.2070.6) X-Spam-Status: No, score=2.5 required=5.0 tests=DKIM_SIGNED, DNS_FROM_AHBL_RHSBL,HTML_MESSAGE,T_DKIM_INVALID,UNPARSEABLE_RELAY autolearn=no version=3.3.2 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on picard.vpn.uxnr.de X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.18 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: multipart/mixed; boundary="===============0599936861==" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" --===============0599936861== Content-Type: multipart/alternative; boundary="Apple-Mail=_8EE3E32A-1EDB-48A5-853D-24C7EDCB1A67" --Apple-Mail=_8EE3E32A-1EDB-48A5-853D-24C7EDCB1A67 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Daniel, > Am 21.02.2015 um 23:48 schrieb Daniel Stenberg : >=20 > Do anyone have any stuff that should go in before a release? And then = I mean something you yourself plan to fix within a week or so. I still have the following things on my personal TODO list, but I cannot = promise to get them done within 2 weeks: add the contributed SecureTransport backend add the contributed CMake build files add support for secure memory clearing add generic support for AES-CTR Best regards, Marc= --Apple-Mail=_8EE3E32A-1EDB-48A5-853D-24C7EDCB1A67 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi Daniel,

Am 21.02.2015 um 23:48 schrieb = Daniel Stenberg <daniel@haxx.se>:

Do anyone have any = stuff that should go in before a release? And then I mean something you = yourself plan to fix within a week or so.

I = still have the following things on my personal TODO list, but I cannot = promise to get them done within 2 weeks:
  • add the contributed = SecureTransport backend
  • add the contributed CMake = build files
  • add support for secure memory = clearing
  • add generic support for = AES-CTR

Best= regards,
Marc
= --Apple-Mail=_8EE3E32A-1EDB-48A5-853D-24C7EDCB1A67-- --===============0599936861== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlic3NoMi1k ZXZlbCBodHRwOi8vY29vbC5oYXh4LnNlL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9saWJzc2gy LWRldmVsCg== --===============0599936861==-- From libssh2-devel-bounces@cool.haxx.se Tue Feb 24 23:12:39 2015 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-7) with ESMTP id t1OMCQD9032127; Tue, 24 Feb 2015 23:12:38 +0100 Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by giant.haxx.se (8.14.4/8.14.4/Debian-7) with ESMTP id t1OMCOa9032010 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 24 Feb 2015 23:12:25 +0100 Received: by lbiw7 with SMTP id w7so28088949lbi.10 for ; Tue, 24 Feb 2015 14:12:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=4gTJTcJkuVxrMtYnYDvXqgcj6i+MsJwjD7zehvsW4Mg=; b=fG1wbd0fFHRspUYxzYm+fFuh5DpProoK7hxHezTATWG7dtoHiFFi3ca18JCEnyE+9Z 6rAZnMMFsKFpkYpAYBTmf860xt6MKSiq+oOQIHNXhTezH4ZO/h0VMA5n4y5BB3J0v3qz LNQHUfIispQtPi0ydb31+G4Tc6NrooVpqmrtmzn4FHV4WkHBKkcFXmfF1hAY8XqFXn0n HwBHyXTgsZ94TYyiyXF6tabUzWXjQ6m58XJqYaKZrNYqr00z0AmQosDvHPG/JDjDq/r0 Lijh1pieKxOkymHV1PJ/Ij99z1NQxkaA4fxeAwc2tspCUZPYMuKAjoJbPnvWgf3bfo4F ogqA== MIME-Version: 1.0 X-Received: by 10.112.63.165 with SMTP id h5mr144398lbs.16.1424815941269; Tue, 24 Feb 2015 14:12:21 -0800 (PST) Received: by 10.25.38.18 with HTTP; Tue, 24 Feb 2015 14:12:21 -0800 (PST) In-Reply-To: References: Date: Tue, 24 Feb 2015 22:12:21 +0000 X-Google-Sender-Auth: KnnVycsKIZbR_1sl7tCjQpaLxL4 Message-ID: Subject: Re: Ok, let's talk release again. For real. From: Alexander Lamaison To: libssh2 development X-MIME-Autoconverted: from quoted-printable to 8bit by giant.haxx.se id t1OMCOa9032010 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.18 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: text/plain; charset="utf-8" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id t1OMCQD9032127 On 24 February 2015 at 20:34, Marc Hörsken wrote: > Hi Daniel, > > Am 21.02.2015 um 23:48 schrieb Daniel Stenberg : > > Do anyone have any stuff that should go in before a release? And then I mean > something you yourself plan to fix within a week or so. > > > I still have the following things on my personal TODO list, but I cannot > promise to get them done within 2 weeks: ...snip > add the contributed CMake build files I was going to wait until after the release before I merge in the CMake build system. Also, I would like some sort of community 'nod' before doing so. If the opinion is that this should go in sooner, just let me know and I'll push it. FWIW, I think it's in pretty good shape and (currently) leaves the existing autotool build system in place for everything other than Windows. Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org) _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Wed Feb 25 00:40:02 2015 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-7) with ESMTP id t1ONddAY032240; Wed, 25 Feb 2015 00:39:58 +0100 Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by giant.haxx.se (8.14.4/8.14.4/Debian-7) with ESMTP id t1ONdcTx032167 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 25 Feb 2015 00:39:38 +0100 Received: by wggy19 with SMTP id y19so248631wgg.10 for ; Tue, 24 Feb 2015 15:39:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qqmail.nl; s=google; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:thread-index:content-language; bh=4x59PdvohF80GE3qqKoLG6TIo+5GY24xdZmGVUSKkFg=; b=K/6+bDz13ZzU3ZVbqXkwVFnqpG0mx0306zBASyahyvy+Rszlfpw8XiaWYuc9Ay7v56 kgKlXyWMoKzieKX6SzOEtuN4C0+k8imqGNxl1Yv1lS25oD6wkFSzQ3qavrFM9QYls/5V CsJG7puF3r0IklbMY35xqDwqufpRihyJjetYY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-type:thread-index:content-language; bh=4x59PdvohF80GE3qqKoLG6TIo+5GY24xdZmGVUSKkFg=; b=eHcPvhcWd3PH9yqxMSmEn9H2UShUlIpC4YAwcEU8vfQAVAYHl0zk7Tycx9Xl46mE6a H8e9iVGQYQkKtourJOiw1m3MrxqKJv0zC6LMr+gm311R9hjXDq4Fj0EKeKSF9ncHmIw7 RcGUZJdN6jaSKo4v9NYWXADldoKvCUmekXoiiQ1a98Nds689eoJlbYvlPqmP8YSLuQr2 +y1LbgX5UfbFAvVD5UewCCIBhJyinLW7REwx/l1iQA66WJd6BANPOBRP1QbunuDNTRQP 6xaDh90zWsU4uYITz7r0P6kmazevaUsSDZgrc7bzdXfgIDn3ADzsJto+XJ9a44ia7ayp ZIzg== X-Gm-Message-State: ALoCoQmdyORFkj1IOaNXhVGCN8kNfY1R3Tnh9Jc2D3/EMAXHPAK+M0n2euMkX12Rr0MaJWdGBHa4 X-Received: by 10.195.12.71 with SMTP id eo7mr641895wjd.3.1424821174399; Tue, 24 Feb 2015 15:39:34 -0800 (PST) Received: from i72600 ([2001:610:66e:0:a1fe:7b28:1850:b511]) by mx.google.com with ESMTPSA id m4sm62278430wjb.25.2015.02.24.15.39.32 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 24 Feb 2015 15:39:33 -0800 (PST) From: "Bert Huijben" To: "'libssh2 development'" References: In-Reply-To: Subject: RE: Ok, let's talk release again. For real. Date: Wed, 25 Feb 2015 00:39:19 +0100 Message-ID: <033901d0508b$1d2b5640$578202c0$@qqmail.nl> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_033A_01D05093.7EEFBE40" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHjgHHSpLE1KsQ7QMQGU/c6ZyUTwwKPXyS4AyIyW8+crIcY4A== Content-Language: nl X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.18 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" This is a multipart message in MIME format. ------=_NextPart_000_033A_01D05093.7EEFBE40 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: libssh2-devel [mailto:libssh2-devel-bounces@cool.haxx.se] On = Behalf Of > Alexander Lamaison > Sent: dinsdag 24 februari 2015 23:12 > To: libssh2 development > Subject: Re: Ok, let's talk release again. For real. >=20 > On 24 February 2015 at 20:34, Marc H=C3=B6rsken = wrote: > > Hi Daniel, > > > > Am 21.02.2015 um 23:48 schrieb Daniel Stenberg : > > > > Do anyone have any stuff that should go in before a release? And = then I mean > > something you yourself plan to fix within a week or so. > > > > > > I still have the following things on my personal TODO list, but I = cannot > > promise to get them done within 2 weeks: > ...snip > > add the contributed CMake build files >=20 > I was going to wait until after the release before I merge in the > CMake build system. Also, I would like some sort of community 'nod' > before doing so. >=20 > If the opinion is that this should go in sooner, just let me know and > I'll push it. FWIW, I think it's in pretty good shape and (currently) > leaves the existing autotool build system in place for everything > other than Windows. I would like to see the Putty Pageant code updated to how it is = currently implemented in putty itself. The current code doesn't support running elevated programs on Windows = using it, while using a pageant as the normal user (or the other way = around). This was fixed in putty a long time ago. I currently use a patch in my own build (that version is attached). I use two helper functions at the bottom of the file to avoid breaking = my patch when something in the file changes... the real implementation = should of course be in the proper locations :) I'll see if I can find a bit of time to cleanup the code later this = week. (And verify if it is still the 'latest' putty code) Bert >=20 > Alex >=20 > -- > Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org) >=20 > _______________________________________________ > libssh2-devel = http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel ------=_NextPart_000_033A_01D05093.7EEFBE40 Content-Type: application/octet-stream; name="pageant-security.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="pageant-security.patch" Index: src/agent.c=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= --- src/agent.c (revision 1622)=0A= +++ src/agent.c (working copy)=0A= @@ -274,10 +274,14 @@=0A= return LIBSSH2_ERROR_NONE;=0A= }=0A= =0A= +static SECURITY_ATTRIBUTES *SharpSvn_CreateSecurityAttributes(HWND = forWindow);=0A= +static void SharpSvn_DestroySecurityAttributes(SECURITY_ATTRIBUTES *sa);=0A= +=0A= static int=0A= agent_transact_pageant(LIBSSH2_AGENT *agent, agent_transaction_ctx_t = transctx)=0A= {=0A= HWND hwnd;=0A= + SECURITY_ATTRIBUTES *psa;=0A= char mapname[23];=0A= HANDLE filemap;=0A= unsigned char *p;=0A= @@ -294,10 +298,14 @@=0A= return _libssh2_error(agent->session, = LIBSSH2_ERROR_AGENT_PROTOCOL,=0A= "found no pageant");=0A= =0A= + psa =3D SharpSvn_CreateSecurityAttributes(hwnd);=0A= +=0A= sprintf(mapname, "PageantRequest%08x", = (unsigned)GetCurrentThreadId());=0A= - filemap =3D CreateFileMapping(INVALID_HANDLE_VALUE, NULL, = PAGE_READWRITE,=0A= + filemap =3D CreateFileMapping(INVALID_HANDLE_VALUE, psa, = PAGE_READWRITE,=0A= 0, PAGEANT_MAX_MSGLEN, mapname);=0A= =0A= + SharpSvn_DestroySecurityAttributes(psa);=0A= +=0A= if (filemap =3D=3D NULL || filemap =3D=3D INVALID_HANDLE_VALUE)=0A= return _libssh2_error(agent->session, = LIBSSH2_ERROR_AGENT_PROTOCOL,=0A= "failed setting up pageant filemap");=0A= @@ -791,3 +799,101 @@=0A= agent_free_identities(agent);=0A= LIBSSH2_FREE(agent->session, agent);=0A= }=0A= +=0A= +/* SharpSvn patch */=0A= +PSID get_user_sid(void)=0A= +{=0A= + HANDLE proc =3D NULL, tok =3D NULL;=0A= + TOKEN_USER *user =3D NULL;=0A= + DWORD toklen, sidlen;=0A= + PSID sid =3D NULL, ret =3D NULL;=0A= +=0A= + if ((proc =3D OpenProcess(MAXIMUM_ALLOWED, FALSE,=0A= + GetCurrentProcessId())) =3D=3D NULL)=0A= + goto cleanup;=0A= +=0A= + if (!OpenProcessToken(proc, TOKEN_QUERY, &tok))=0A= + goto cleanup;=0A= +=0A= + if (!GetTokenInformation(tok, TokenUser, NULL, 0, &toklen) &&=0A= + GetLastError() !=3D ERROR_INSUFFICIENT_BUFFER)=0A= + goto cleanup;=0A= +=0A= + if ((user =3D (TOKEN_USER *)LocalAlloc(LPTR, toklen)) =3D=3D NULL)=0A= + goto cleanup;=0A= +=0A= + if (!GetTokenInformation(tok, TokenUser, user, toklen, &toklen))=0A= + goto cleanup;=0A= +=0A= + sidlen =3D GetLengthSid(user->User.Sid);=0A= +=0A= + sid =3D (PSID)LocalAlloc(LPTR, sidlen);=0A= +=0A= + if (!CopySid(sidlen, sid, user->User.Sid))=0A= + goto cleanup;=0A= +=0A= + /* Success. Move sid into the return value slot, and null it out=0A= + * to stop the cleanup code freeing it. */=0A= + ret =3D sid;=0A= + sid =3D NULL;=0A= +=0A= + cleanup:=0A= + if (proc !=3D NULL)=0A= + CloseHandle(proc);=0A= + if (tok !=3D NULL)=0A= + CloseHandle(tok);=0A= + if (user !=3D NULL)=0A= + LocalFree(user);=0A= + if (sid !=3D NULL)=0A= + free(sid);=0A= +=0A= + return ret;=0A= +}=0A= +=0A= +static SECURITY_ATTRIBUTES *SharpSvn_CreateSecurityAttributes(HWND = forWindow)=0A= +{=0A= + SECURITY_ATTRIBUTES *psa;=0A= + SECURITY_DESCRIPTOR *psd;=0A= + PSID usersid;=0A= + if (!forWindow)=0A= + return NULL;=0A= +=0A= + /*=0A= + * Make the file mapping we create for communication with=0A= + * Pageant owned by the user SID rather than the default. This=0A= + * should make communication between processes with slightly=0A= + * different contexts more reliable: in particular, command=0A= + * prompts launched as administrator should still be able to=0A= + * run PSFTPs which refer back to the owning user's=0A= + * unprivileged Pageant.=0A= + */=0A= + usersid =3D get_user_sid();=0A= +=0A= + if (usersid) {=0A= + psd =3D (SECURITY_DESCRIPTOR*)LocalAlloc(LPTR, sizeof(*psd));=0A= + psa =3D (SECURITY_ATTRIBUTES*)LocalAlloc(LPTR, sizeof(*psa));=0A= + if (psa && psd) {=0A= + if (InitializeSecurityDescriptor(psd, = SECURITY_DESCRIPTOR_REVISION) &&=0A= + SetSecurityDescriptorOwner(psd, usersid, FALSE)) {=0A= + psa->nLength =3D sizeof(*psa);=0A= + psa->bInheritHandle =3D FALSE;=0A= + psa->lpSecurityDescriptor =3D psd;=0A= + return psa;=0A= + } else {=0A= + LocalFree(psd);=0A= + LocalFree(psa);=0A= + }=0A= + }=0A= + LocalFree(usersid);=0A= + }=0A= +=0A= + return NULL;=0A= +}=0A= +=0A= +static void SharpSvn_DestroySecurityAttributes(SECURITY_ATTRIBUTES *sa)=0A= +{=0A= + if (sa) {=0A= + LocalFree(sa->lpSecurityDescriptor);=0A= + LocalFree(sa);=0A= + }=0A= +}=0A= ------=_NextPart_000_033A_01D05093.7EEFBE40 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlic3NoMi1k ZXZlbCBodHRwOi8vY29vbC5oYXh4LnNlL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9saWJzc2gy LWRldmVsCg== ------=_NextPart_000_033A_01D05093.7EEFBE40-- From libssh2-devel-bounces@cool.haxx.se Wed Feb 25 03:41:21 2015 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-7) with ESMTP id t1P2eLDK016631; Wed, 25 Feb 2015 03:41:17 +0100 Received: from foo.stuge.se (qmailr@foo.stuge.se [212.116.89.98]) by giant.haxx.se (8.14.4/8.14.4/Debian-7) with ESMTP id t1P2eJFv016627 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 25 Feb 2015 03:40:19 +0100 Received: (qmail 4508 invoked by uid 501); 25 Feb 2015 02:40:20 -0000 Message-ID: <20150225024020.4507.qmail@stuge.se> Date: Wed, 25 Feb 2015 03:40:20 +0100 From: Peter Stuge To: libssh2-devel@cool.haxx.se Subject: Re: Ok, let's talk release again. For real. Mail-Followup-To: libssh2-devel@cool.haxx.se References: <033901d0508b$1d2b5640$578202c0$@qqmail.nl> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <033901d0508b$1d2b5640$578202c0$@qqmail.nl> X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.18 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: text/plain; charset="utf-8" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id t1P2eLDK016631 Bert Huijben wrote: > I currently use a patch in my own build (that version is attached). Is the new code backwards compatible - ie. works also with older versions of pageant? //Peter _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Wed Feb 25 08:32:49 2015 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-7) with ESMTP id t1P7WR0H027942; Wed, 25 Feb 2015 08:32:46 +0100 Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by giant.haxx.se (8.14.4/8.14.4/Debian-7) with ESMTP id t1P7WPbF027651 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 25 Feb 2015 08:32:26 +0100 Received: by wesq59 with SMTP id q59so1805162wes.1 for ; Tue, 24 Feb 2015 23:32:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qqmail.nl; s=google; h=message-id:mime-version:to:from:subject:date:in-reply-to:references :content-type; bh=EUe/3TM6tw/vTnnOuP+z4OazFtztt5FNKefHgVkMH1A=; b=MwDOl545IOwdPDJYYxg3py/l9BP64l5dbuJ1D2hmYtF3yi6ZxjrmlxAh4z7Cll5WSs btS2f/oIDp+9FM2asjmuVySWPuFjI+kaU+D6jZgeJHB04ETErSrtXqeChVDwLHHaQOYv NhHJkvo/V368KMdBoHJ7JhssiHMJz0Ee4X2Qw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:mime-version:to:from:subject:date :in-reply-to:references:content-type; bh=EUe/3TM6tw/vTnnOuP+z4OazFtztt5FNKefHgVkMH1A=; b=NIfmpbselWSKUpxG5br83FiANFulCAWuyAdmXrmrdrSgUpwJxHh2vmR4YK4y+1+H/r dNUy+EN7+3OgEafykJG8U/DlXdwJmXMFYB3LkbWCx5F/1+Z5V6XE6viNlpdZFygk0CCM 6KEdveJRO+Jkwz3/OubyQa+3WIL3YAfH1PCg1gRAbL0VMzIF+XEF49JAJ8vhjSumu4Ei LJreM+Y+wJxvNVFR69RsZRYf5szX8yz+tYYyc+74xHBQ8y+Bp18PMO27BG0qQ29RpNXl D27LQUgsCrS6nm4COyT3R50UT78sXSNDhqkbIUwwPdoq1GUVx3Gj75FCOMnG2FgnRNa4 v+4g== X-Gm-Message-State: ALoCoQm1HYNRQsCHds8K/IVlpO38QkCPxDNbOzkB2wNLZHyL3i2mIUdFMj/lX8CG6gXfdVoqcyy1 X-Received: by 10.180.206.98 with SMTP id ln2mr37421237wic.94.1424849541355; Tue, 24 Feb 2015 23:32:21 -0800 (PST) Received: from ?IPv6:2001:610:66e:0:2417:a4b2:3a0b:95c3? ([2001:610:66e:0:2417:a4b2:3a0b:95c3]) by mx.google.com with ESMTPSA id cf12sm63525778wjb.10.2015.02.24.23.32.19 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 24 Feb 2015 23:32:20 -0800 (PST) Message-ID: <54ed7a84.ac5bc20a.5990.4796@mx.google.com> MIME-Version: 1.0 To: libssh2 development From: Bert Huijben Subject: RE: Ok, let's talk release again. For real. Date: Wed, 25 Feb 2015 08:32:22 +0100 In-Reply-To: <20150225024020.4507.qmail@stuge.se> References: <033901d0508b$1d2b5640$578202c0$@qqmail.nl> <20150225024020.4507.qmail@stuge.se> X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.18 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: multipart/mixed; boundary="===============0145836391==" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" --===============0145836391== Content-Type: multipart/alternative; boundary="_DB40DCFE-5B66-4C52-9DC1-3C4716920911_" --_DB40DCFE-5B66-4C52-9DC1-3C4716920911_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Yes the code is compatible with older versions. The only difference is that= the file that is used as communication channel between the processes is op= ened/created with rights for more user tokens than a 100% token match.=20 (Verified myself, and thoroughly documented in the putty source code) Bert -----Original Message----- From: "Peter Stuge" Sent: =E2=80=8E25-=E2=80=8E2-=E2=80=8E2015 03:42 To: "libssh2-devel@cool.haxx.se" Subject: Re: Ok, let's talk release again. For real. Bert Huijben wrote:=0A= > I currently use a patch in my own build (that version is attached).=0A= =0A= Is the new code backwards compatible - ie. works also with older=0A= versions of pageant?=0A= =0A= =0A= //Peter=0A= _______________________________________________=0A= libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel=0A= --_DB40DCFE-5B66-4C52-9DC1-3C4716920911_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Yes the code is compatible with older versions. The only = difference is that the file that is used as communication channel between t= he processes is opened/created with rights for more user tokens than a 100%= token match.
(Verified myself, and thoroughly documented in the putty = source code)

Bert

From: Peter Stuge
Sent: =E2= =80=8E25-=E2=80=8E2-=E2=80=8E2015 03:42
To: libssh2-devel@cool.haxx.se

<= span style=3D"font-family: Calibri,sans-serif; font-size: 11pt; font-weight= : bold;">Subject:
Re: Ok, let's talk release again. For real.

<= /div>Bert Huijben wrote:
> I currently use a patch in my own build (t= hat version is attached).

Is the new code backwards compatible - ie.= works also with older
versions of pageant?


//Peter
______= _________________________________________
libssh2-devel http://cool.haxx= .se/cgi-bin/mailman/listinfo/libssh2-devel
= --_DB40DCFE-5B66-4C52-9DC1-3C4716920911_-- --===============0145836391== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlic3NoMi1k ZXZlbCBodHRwOi8vY29vbC5oYXh4LnNlL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9saWJzc2gy LWRldmVsCg== --===============0145836391==-- From libssh2-devel-bounces@cool.haxx.se Thu Feb 26 17:10:12 2015 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-7) with ESMTP id t1QG9iPh019718; Thu, 26 Feb 2015 17:10:08 +0100 Received: from earth.stuge.se (earth.stuge.se [212.116.89.126]) by giant.haxx.se (8.14.4/8.14.4/Debian-7) with ESMTP id t1QG9hcF019709 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 26 Feb 2015 17:09:43 +0100 Received: (qmail 3033 invoked from network); 26 Feb 2015 16:12:38 -0000 Received: from unknown (HELO earth.stuge.se) (127.0.0.1) by localhost with SMTP; 26 Feb 2015 16:12:38 -0000 MIME-Version: 1.0 From: "libssh2 Trac" X-Trac-Version: 1.0dev Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 1.0dev, by Edgewall Software To: kees.dekker@infor.com, utkej1@gmail.com X-Trac-Project: libssh2 Date: Thu, 26 Feb 2015 16:12:38 -0000 X-URL: https://trac.libssh2.org/ Subject: Re: [libssh2] #273: build of libssh2-1.4.3 failed on Solaris 10 when specifying --with-libssl-prefix X-Trac-Ticket-URL: https://trac.libssh2.org/ticket/273#comment:1 Message-ID: <059.1a76ba6593e7833904785ce963f64273@libssh2.stuge.se> References: <044.7e9de3f4fe3635c4e50ee8eab97b444b@libssh2.stuge.se> X-Trac-Ticket-ID: 273 In-Reply-To: <044.7e9de3f4fe3635c4e50ee8eab97b444b@libssh2.stuge.se> X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id t1QG9hcF019709 Cc: libssh2-devel@cool.haxx.se X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.18 List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: trac@libssh2.stuge.se, libssh2 development Content-Type: text/plain; charset="utf-8" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id t1QG9iPh019718 #273: build of libssh2-1.4.3 failed on Solaris 10 when specifying --with-libssl- prefix ----------------------+------------------------------- Reporter: kdekker | Owner: Type: defect | Status: new Priority: normal | Milestone: 1.4.3 Component: misc | Version: 1.4.2 Resolution: | Keywords: configure failure Blocked By: | Blocks: ----------------------+------------------------------- Comment (by utke): This configure option fails on a variety of linux distros, not just solaris. There doesn't seem to be any logic related to --with-libssl-prefix in either the configure.ac or any of the m4 files. There is only the comment in the error message that mentions it. Plus there are various e-mail threads on the same issue showing up when search for the problem. -- Ticket URL: libssh2 C library for writing portable SSH2 clients _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Fri Feb 27 10:11:47 2015 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-7) with ESMTP id t1R9BLRG016054; Fri, 27 Feb 2015 10:11:45 +0100 Received: from earth.stuge.se (earth.stuge.se [212.116.89.126]) by giant.haxx.se (8.14.4/8.14.4/Debian-7) with ESMTP id t1R9BKMO016011 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 27 Feb 2015 10:11:20 +0100 Received: (qmail 4756 invoked from network); 27 Feb 2015 09:14:16 -0000 Received: from unknown (HELO earth.stuge.se) (127.0.0.1) by localhost with SMTP; 27 Feb 2015 09:14:16 -0000 MIME-Version: 1.0 From: "libssh2 Trac" X-Trac-Version: 1.0dev Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 1.0dev, by Edgewall Software To: mzet@owasp.org X-Trac-Project: libssh2 Date: Fri, 27 Feb 2015 09:14:16 -0000 X-URL: https://trac.libssh2.org/ Subject: [libssh2] #294: DoS condition: read from unmapped memory region causes libssh2 to crash X-Trac-Ticket-URL: https://trac.libssh2.org/ticket/294 Message-ID: <041.8802528337a07a3a2631f04dc8cb92f0@libssh2.stuge.se> X-Trac-Ticket-ID: 294 X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id t1R9BKMO016011 Cc: libssh2-devel@cool.haxx.se X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.18 List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: trac@libssh2.stuge.se, libssh2 development Content-Type: text/plain; charset="utf-8" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id t1R9BLRG016054 #294: DoS condition: read from unmapped memory region causes libssh2 to crash ----------------------+-------------------- Reporter: mzet | Owner: Type: defect | Status: new Priority: high | Milestone: 1.4.3 Component: protocol | Version: Keywords: security | Blocked By: Blocks: | ----------------------+-------------------- Affected are versions 1.4.3 and latest development version. Issue ===== Specifically crafted input from ssh server causes read access from unmapped memory region resulting in crash (Segmentation fault) and causing denial of service condition. Valgrind output: ==3670== Process terminating with default action of signal 11 (SIGSEGV) ==3670== Access not within mapped region at address 0x6AA107D8 ==3670== at 0x4087DB: _libssh2_ntohu32 (misc.c:163) ==3670== by 0x419E62: kex_agree_methods (kex.c:1583) ==3670== by 0x41A5CB: _libssh2_kex_exchange (kex.c:1749) ==3670== by 0x40C964: session_startup (session.c:723) ==3670== by 0x40CC04: libssh2_session_handshake (session.c:801) ==3670== by 0x402BCE: main (ssh2.c:118) The issue is caused by following code in kex.c:kex_agree_methods(...) function: /* Locate each string */ kex_len = _libssh2_ntohu32(s); kex = s + 4; s += 4 + kex_len; hostkey_len = _libssh2_ntohu32(s); hostkey = s + 4; s += 4 + hostkey_len; crypt_cs_len = _libssh2_ntohu32(s); crypt_cs = s + 4; s += 4 + crypt_cs_len; crypt_sc_len = _libssh2_ntohu32(s); crypt_sc = s + 4; s += 4 + crypt_sc_len; mac_cs_len = _libssh2_ntohu32(s); mac_cs = s + 4; s += 4 + mac_cs_len; mac_sc_len = _libssh2_ntohu32(s); mac_sc = s + 4; s += 4 + mac_sc_len; comp_cs_len = _libssh2_ntohu32(s); comp_cs = s + 4; s += 4 + comp_cs_len; comp_sc_len = _libssh2_ntohu32(s); comp_sc = s + 4; It can be observed that various length fields (kex_len, hostkey_len, mac_cs_len, etc.) are taken from (untrusted) input and are used as offsets to memory location ('s' pointer) without any validation. Reproduction ============ I'm attaching 'crash.input' file, an example of input that triggers this issue which could be reproduced with following steps: Run malicious 'ssh server': # cat crash.input | nc -l -p 22 Run ssh2 from libssh2/example: $ ./ssh2 127.0.0.1 Fix === Proposed patch that fixes this issue is attached. -- Ticket URL: libssh2 C library for writing portable SSH2 clients _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel From libssh2-devel-bounces@cool.haxx.se Sat Feb 28 22:47:33 2015 Return-Path: Received: from www.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-7) with ESMTP id t1SLl7Jc013263; Sat, 28 Feb 2015 22:47:28 +0100 Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by giant.haxx.se (8.14.4/8.14.4/Debian-7) with ESMTP id t1SLl6NL012970 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Sat, 28 Feb 2015 22:47:06 +0100 Received: by wesw55 with SMTP id w55so26508628wes.5 for ; Sat, 28 Feb 2015 13:47:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qqmail.nl; s=google; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=9E9stuBCIIMxRQkMQsmNvPVvJZEygYyDGZSlJQ4vdOg=; b=JVZ0iKyaYJZZcrceouBWivb5Ws4QSFEHusMYWSiABjqpnNCGRX4cjNy3AxWaSeDGQW Mgb0L1wBCa+DGr/cGkLKOkHeSANEi4NTLeOmuWNZRZrkCzAvSZ1NaFEIaCAD9wMZYWg/ UJkKwFoH7FL2p2eJibTxAJL2Tu744c/cTsOkc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :thread-index:content-language; bh=9E9stuBCIIMxRQkMQsmNvPVvJZEygYyDGZSlJQ4vdOg=; b=AVmz/fy7xWEzL2fnrxjh9+59P7yL6yd7wzRKjQCjyZd26Q/361lzP9FGqf/c6IiwML 868oZ8YQ3KJPaT0BiQs9mRR8AZsldloG4Az+H4VEVIrjaYHCA0Et6ldcKPsJp/A/3mnG O14OrgX0zZousohRmaT2YJSDnVCMZYYLGbE7z77+4ktiYAKS0Oc5/FnDQv8WB+bzuQ/G BEwL6djRc1ExIlFFLLU97SpGZrFAvqkeCxmf/D5aGVW+cH/s7Iq8W5G7FOPJaZOS5tvK FC+A83umHMi5eYLE1Glw5U9OzPbjGLm0Dj9Qv6iXVySi8GYLQ3I8RuEvThzivFn4fahk bE7Q== X-Gm-Message-State: ALoCoQkkAueTNPALFcLkbVfTryuQXQqpb9vwxnhCeqKIcGspA3UJ+TS6NHcLMfd/enyWXVHXMG88 X-Received: by 10.194.172.35 with SMTP id az3mr43054744wjc.43.1425160022426; Sat, 28 Feb 2015 13:47:02 -0800 (PST) Received: from i72600 ([2001:610:66e:0:a1fe:7b28:1850:b511]) by mx.google.com with ESMTPSA id lg18sm8626412wic.23.2015.02.28.13.47.00 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 28 Feb 2015 13:47:00 -0800 (PST) From: "Bert Huijben" To: "'libssh2 development'" References: <033901d0508b$1d2b5640$578202c0$@qqmail.nl> <20150225024020.4507.qmail@stuge.se> In-Reply-To: <20150225024020.4507.qmail@stuge.se> Subject: RE: Ok, let's talk release again. For real. Date: Sat, 28 Feb 2015 22:46:43 +0100 Message-ID: <007101d053a0$0b65fb50$2231f1f0$@qqmail.nl> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHjgHHSpLE1KsQ7QMQGU/c6ZyUTwwKPXyS4AyIyW88CdzjdAQKiqjDvnInhr8A= Content-Language: nl X-MIME-Autoconverted: from quoted-printable to 8bit by giant.haxx.se id t1SLl6NL012970 X-BeenThere: libssh2-devel@cool.haxx.se X-Mailman-Version: 2.1.18 Precedence: list List-Id: libssh2 development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: libssh2 development Content-Type: text/plain; charset="utf-8" Errors-To: libssh2-devel-bounces@cool.haxx.se Sender: "libssh2-devel" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by giant.haxx.se id t1SLl7Jc013263 > -----Original Message----- > From: libssh2-devel [mailto:libssh2-devel-bounces@cool.haxx.se] On Behalf Of > Peter Stuge > Sent: woensdag 25 februari 2015 03:40 > To: libssh2-devel@cool.haxx.se > Subject: Re: Ok, let's talk release again. For real. > > Bert Huijben wrote: > > I currently use a patch in my own build (that version is attached). > > Is the new code backwards compatible - ie. works also with older > versions of pageant? The relevant change in putty's own code is in r9043 (svn://svn.tartarus.org/sgt/putty) [[ ------------------------------------------------------------------------ r9043 | simon | 2010-12-23 16:22:50 +0100 (do, 23 dec 2010) | 5 lines Changed paths: M /putty/windows/winpgntc.c M /putty/windows/winstuff.h More careful owner SID selection in the Pageant client code. This should solve some of the SID-mismatch issues we've occasionally had reported. Because it's a modification on the client side, it doesn't affect the security of Pageant itself. Index: putty/windows/winstuff.h =================================================================== --- putty/windows/winstuff.h (revision 9042) +++ putty/windows/winstuff.h (revision 9043) @@ -96,9 +96,9 @@ #define STR1(x) #x #define STR(x) STR1(x) #define GET_WINDOWS_FUNCTION_PP(module, name) \ - p_##name = module ? (t_##name) GetProcAddress(module, STR(name)) : NULL + (p_##name = module ? (t_##name) GetProcAddress(module, STR(name)) : NULL) #define GET_WINDOWS_FUNCTION(module, name) \ - p_##name = module ? (t_##name) GetProcAddress(module, #name) : NULL + (p_##name = module ? (t_##name) GetProcAddress(module, #name) : NULL) /* * Global variables. Most modules declare these `extern', but Index: putty/windows/winpgntc.c =================================================================== --- putty/windows/winpgntc.c (revision 9042) +++ putty/windows/winpgntc.c (revision 9043) @@ -7,6 +7,10 @@ #include "putty.h" +#ifndef NO_SECURITY +#include +#endif + #define AGENT_COPYDATA_ID 0x804e50ba /* random goop */ #define AGENT_MAX_MSGLEN 8192 @@ -66,6 +70,33 @@ #endif +/* + * Dynamically load advapi32.dll for SID manipulation. In its absence, + * we degrade gracefully. + */ +#ifndef NO_SECURITY +int advapi_initialised = FALSE; +static HMODULE advapi; +DECL_WINDOWS_FUNCTION(static, BOOL, OpenProcessToken, + (HANDLE, DWORD, PHANDLE)); +DECL_WINDOWS_FUNCTION(static, BOOL, GetTokenInformation, + (HANDLE, TOKEN_INFORMATION_CLASS, + LPVOID, DWORD, PDWORD)); +DECL_WINDOWS_FUNCTION(static, BOOL, InitializeSecurityDescriptor, + (PSECURITY_DESCRIPTOR, DWORD)); +DECL_WINDOWS_FUNCTION(static, BOOL, SetSecurityDescriptorOwner, + (PSECURITY_DESCRIPTOR, PSID, BOOL)); +static int init_advapi(void) +{ + advapi = load_system32_dll("advapi32.dll"); + return advapi && + GET_WINDOWS_FUNCTION(advapi, OpenProcessToken) && + GET_WINDOWS_FUNCTION(advapi, GetTokenInformation) && + GET_WINDOWS_FUNCTION(advapi, InitializeSecurityDescriptor) && + GET_WINDOWS_FUNCTION(advapi, SetSecurityDescriptorOwner); +} +#endif + int agent_query(void *in, int inlen, void **out, int *outlen, void (*callback)(void *, void *, int), void *callback_ctx) { @@ -75,6 +106,10 @@ unsigned char *p, *ret; int id, retlen; COPYDATASTRUCT cds; + SECURITY_ATTRIBUTES sa, *psa; + PSECURITY_DESCRIPTOR psd = NULL; + HANDLE proc, tok; + TOKEN_USER *user = NULL; *out = NULL; *outlen = 0; @@ -83,7 +118,57 @@ if (!hwnd) return 1; /* *out == NULL, so failure */ mapname = dupprintf("PageantRequest%08x", (unsigned)GetCurrentThreadId()); - filemap = CreateFileMapping(INVALID_HANDLE_VALUE, NULL, PAGE_READWRITE, + +#ifndef NO_SECURITY + if (advapi_initialised || init_advapi()) { + /* + * Make the file mapping we create for communication with + * Pageant owned by the user SID rather than the default. This + * should make communication between processes with slightly + * different contexts more reliable: in particular, command + * prompts launched as administrator should still be able to + * run PSFTPs which refer back to the owning user's + * unprivileged Pageant. + */ + + if ((proc = OpenProcess(MAXIMUM_ALLOWED, FALSE, + GetCurrentProcessId())) != NULL) { + if (p_OpenProcessToken(proc, TOKEN_QUERY, &tok)) { + DWORD retlen; + p_GetTokenInformation(tok, TokenUser, NULL, 0, &retlen); + user = (TOKEN_USER *)LocalAlloc(LPTR, retlen); + if (!p_GetTokenInformation(tok, TokenUser, + user, retlen, &retlen)) { + LocalFree(user); + user = NULL; + } + CloseHandle(tok); + } + CloseHandle(proc); + } + + psa = NULL; + if (user) { + psd = (PSECURITY_DESCRIPTOR) + LocalAlloc(LPTR, SECURITY_DESCRIPTOR_MIN_LENGTH); + if (psd) { + if (p_InitializeSecurityDescriptor + (psd, SECURITY_DESCRIPTOR_REVISION) && + p_SetSecurityDescriptorOwner(psd, user->User.Sid, FALSE)) { + sa.nLength = sizeof(sa); + sa.bInheritHandle = TRUE; + sa.lpSecurityDescriptor = psd; + psa = &sa; + } else { + LocalFree(psd); + psd = NULL; + } + } + } + } +#endif /* NO_SECURITY */ + + filemap = CreateFileMapping(INVALID_HANDLE_VALUE, psa, PAGE_READWRITE, 0, AGENT_MAX_MSGLEN, mapname); if (filemap == NULL || filemap == INVALID_HANDLE_VALUE) return 1; /* *out == NULL, so failure */ @@ -134,5 +219,9 @@ } UnmapViewOfFile(p); CloseHandle(filemap); + if (psd) + LocalFree(psd); + if (user) + LocalFree(user); return 1; } ]] After that pageant was updated to allow both this extended value as the previous value in r9178, r9264, to extend the number of supported use cases even more. The change itself is not relevant, but let me quote r9264's log message: [[ r9264 | simon | 2011-08-13 16:48:36 +0200 (za, 13 aug 2011) | 8 lines Readjust Pageant's SID check _again_, to make it the union of the policies before and after r9178, and hence able to talk to both 0.60-like and 0.61-like clients. I had failed to consider that many pieces of code derived from PuTTY would have imported the Pageant client code, so we shouldn't randomly stop supporting things just because _we_ aren't using them anymore. ]] The code in libssh2 clearly falls in this category. Bert _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel