tinc rel 1.0.1 gets aborted in OPENSSL call

[Luke Kenneth Casson Leighton]

> 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 at nl.linux.org
Archive: http://mail.nl.linux.org/tinc-devel/