tinc devel - Oct 2003 - tinc rel 1.0.1 gets aborted in OPENSSL call

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

> 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/