[Help-gnutls] Re: gnutls_record_send() problem
simon at josefsson.org
Thu Jan 24 14:28:24 CET 2008
Laurent Birtz <laurent.birtz at kryptiva.com> 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.
> Yes, both processes are blocked for reading.
>> 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
> I guess it depends on other factors than just the version of
> GnuTLS. The problem is gone in the latest version.
More information about the Gnutls-help