[gnutls-dev] RFH gnutls related crash of exim4 on x86_64 (Bug#412886)

[Simon Josefsson]

Andreas Metzler <ametzler at downhill.at.eu.org> writes:

> #0  _gnutls_read_uint16 (data=0x0) at gnutls_num.c:120
> 120     gnutls_num.c: No such file or directory.
>         in gnutls_num.c
> (gdb) bt
> #0  _gnutls_read_uint16 (data=0x0) at gnutls_num.c:120
> #1  0x00002ba3e841bfc9 in _gnutls_proc_rsa_client_kx (session=0x629e10,
>     data=0x0, _data_size=61) at auth_rsa.c:213
      ^^^^^^^^^^^^^^^^^^^^^^^

Interesting, data is NULL here, as invoked from this function:

> #2  0x00002ba3e84171e9 in _gnutls_recv_client_kx_message (session=0x629e10)
>     at gnutls_kx.c:333

The function reads:

      ret =
	_gnutls_recv_handshake (session, &data,
				&datasize,
				GNUTLS_HANDSHAKE_CLIENT_KEY_EXCHANGE,
				MANDATORY_PACKET);
      if (ret < 0)
	return ret;

      ret =
	session->internals.auth_struct->
	gnutls_process_client_kx (session, data, datasize);
      gnutls_free (data);
      if (ret < 0)
	return ret;

Reading the source for _gnutls_recv_handshake, it seems to be possible
for it to return >= 0 if the code received a
GNUTLS_HANDSHAKE_CLIENT_HELLO or GNUTLS_HANDSHAKE_SERVER_HELLO packet.
I'm not 100 % certain of this though.

> #3  0x00002ba3e8412c72 in _gnutls_handshake_server (session=0x629e10)
>     at gnutls_handshake.c:2259
> #4  0x00002ba3e841236b in gnutls_handshake (session=0x629e10)
>     at gnutls_handshake.c:1908
> #5  0x00000000004604a7 in tls_server_start (require_ciphers=0x0)
>     at tls-gnu.c:838
> #6  0x0000000000459339 in smtp_setup_msg () at smtp_in.c:3212
> #7  0x0000000000418fc3 in handle_smtp_call (listen_sockets=0x5e3cd0,
>     listen_socket_count=6, accept_socket=0, accepted=0x0) at daemon.c:495
> #8  0x000000000041a55c in daemon_go () at daemon.c:1815
> #9  0x000000000042848b in main (argc=7, cargv=0x0) at exim.c:3922
> ---
>
> Please let me know if you want any more information.

If you can reproduce the crash in gdb, try getting a backtrace using 'bt
full', and invoke 'up' until you are in the _gnutls_recv_handshake stack
frame, then 'p recv_type'.  If it is indeed
GNUTLS_HANDSHAKE_CLIENT_HELLO or GNUTLS_HANDSHAKE_SERVER_HELLO then I
think we have diagnosed the cause.

It may be that the client got confused and started sending client
hello's all over, and this confused the GnuTLS state machine.  Of
course, it shouldn't be possible to crash it.

Debugging exactly why the other end sends these funny messages would be
the next step, I'm not sure that if we would fix the crash that the
hosts will be able to handshake properly.

Any chance to contact the remote host to find out what software it is
using?

/Simon