Hallo, I?m using tincd now since the old days of 1.0pre4 and ist pretty good software. Ths week I went to upgrade from 1.0pre7 to 1.0.1 and failed. The tincd process gets aborted inside the libcrypto library with OPENSSL_assert (inl >0). Tracking down that problem I found, that the EVP_DecryptUpdate gets called in meta.c with the last argument containing a negativ value (lenin is -204). The process sits in my server and waits for incoming connections. In the middle of the first connection handshaking (via a TCP connection), the server hosted process gets aborted. The remote end sees a timeout. For now I went back to 1.0pre8, but it would be great, to see the new thing running. If you need more information, help or resources, please, mail me. Best regards Johannes Lode -- TINC development list, tinc-devel@nl.linux.org Archive: http://mail.nl.linux.org/tinc-devel/
On Fri, Oct 10, 2003 at 02:49:26PM +0200, Johannes Lode wrote:> Ths week I went to upgrade from 1.0pre7 to 1.0.1 and failed. The tincd > process gets aborted inside the libcrypto library with OPENSSL_assert > (inl >0). > > Tracking down that problem I found, that the EVP_DecryptUpdate gets > called in meta.c with the last argument containing a negativ value > (lenin is -204).That's very strange, because lenin is checked right before EVP_DecryptUpdate is called, and if lenin <= 0, it closes the connection.> For now I went back to 1.0pre8, but it would be great, to see the new > thing running.It's also strange that 1.0pre8 is working without problems, because almost nothing has been changed in meta.c...> If you need more information, help or resources, please, mail me.Could you make sure you have a tincd compiled with the -g option, and get a core dump, and then send me the tincd binary and the coredump? (But note that this will expose your private keys.) -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus@sliepen.eu.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://brouwer.uvt.nl/pipermail/tinc-devel/attachments/20031010/081b1faa/attachment.pgp
Luke Kenneth Casson Leighton
2003-Oct-29 01:45 UTC
tinc rel 1.0.1 gets aborted in OPENSSL call
> week I went to upgrade from 1.0pre7 to 1.0.1 and failed. The tincd > > process gets aborted inside the libcrypto library with > > OPENSSL_assert > > (inl >0). > > > > Tracking down that problem I found, that the EVP_DecryptUpdate gets > > called in meta.c with the last argument containing a negativ value > > (lenin is -204). > > That's very strange, because lenin is checked right before > EVP_DecryptUpdate is called, and if lenin <= 0, it closes the > connection.looking at version 1.0.1 code, line 122 of meta.c has lenin = recv(...). then it is checked (line 124). at line 140, you have while (lenin) { ... } then you pass in lenin into DecryptUpdate, and lenin gets modified to a "new" value. looking at the manage for EVP_DecryptUpdate it says something about if padding is enabled you must have enough space for the decrypted block, so there's a possibility that lenin will be different after the call. later on, with receiving tcp packets, lenin is shrunk by the size of the tcplen packet, and if we didn't get enough data, go back to the beginning of the while loop, at 140. BUT!!! before that jump happens, tcplen is reset to 0. so we have a case where, if receive_tcppacket gets less data than the entire size of the tcp packet, i believe it may be possible to get into a weird state. where: - lenin is non-zero - tcplen is zero - the entire tcp packet has not yet been read consequently, things could go thoroughly pear-shaped, including possibly lenin going negative, as noted. so, really: - there should be checks added to ensure that lenin never goes negative (while lenin >= 0) and then after the while loop, report a possible error condition if lenin < 0 - resetting c->tcplen to 0 probably isn't a good idea [unless i have misunderstood things here]. it _could_ just be that a decrypt has failed [the error condition of EVP_DecryptUpdate isn't checked nor an error reported] ... am i helping? :) l. -- -- expecting email to be received and understood is a bit like picking up the telephone and immediately dialing without checking for a dial-tone; speaking immediately without listening for either an answer or ring-tone; hanging up immediately and then expecting someone to call you (and to be able to call you). -- every day, people send out email expecting it to be received without being tampered with, read by other people, delayed or simply - without prejudice but lots of incompetence - destroyed. -- please therefore treat email more like you would a CB radio to communicate across the world (via relaying stations): ask and expect people to confirm receipt; send nothing that you don't mind everyone in the world knowing about... -- TINC development list, tinc-devel@nl.linux.org Archive: http://mail.nl.linux.org/tinc-devel/