[Help-gnutls] Re: gnutls_record_send() problem

[Simon Josefsson]

Laurent Birtz <address@hidden> writes:

> Simon Josefsson wrote:
>> I can reproduce this.  The reason is this: The server is waiting for the
>> client to send something, which it echoes back, but since the client
>> never sends anything (a zero string is no data) the server never
>> responds, and the client is stuck waiting for input from the server.
>>
>> /Simon
>>   
> Yes, both processes are blocked for reading.

Right.

>> The gnutls_record_send function takes a buffer and a length indicator,
>> so the first seems OK to me.  The latter would be incorrect, 'ret' is
>> used as the return value in that function, not a length indicator.
>> Maybe you could clarify what change you are thinking of?
>
> Well, calling strlen() on a buffer received from a client is a
> security hole (I guess it's OK in the case of an example).

In this example, I don't see a problem.  The relevant code is:

  char buffer[MAX_BUF + 1];
...
          memset (buffer, 0, MAX_BUF + 1);
          ret = gnutls_record_recv (session, buffer, MAX_BUF);
...
              /* echo data back to the client
               */
              gnutls_record_send (session, buffer, strlen (buffer));

Thus strlen will always hit the 0 after the string received from the
client, if not sooner.

> In this context 'ret' is the number of bytes read by
> gnutls_record_recv(), so it is a length indicator.

Ok.  I looked at the client code when I made that comment.

> I assume strlen() was used to avoid counting the terminating 0.

Right.  It is a echo client/server for simple strings.  If you want to
use it for any other purpose, you need to rewrite it.

>> I can't reproduce this.  Are you using the verbatim example source code?
>> Below is what 'valgrind ./ex-client1' prints for me when ex-serv-anon is
>> running.
>
> I guess it depends on other factors than just the version of
> GnuTLS. The problem is gone in the latest version.

Good!

/Simon