mainGnuTLS - Support: sr #106491, Memory corruption in rehandshake


sr #106491: Memory corruption in rehandshake

Submitter:  Sam Varshavchik <mrsam>
Submitted:  Sun 14 Sep 2008 03:50:44 AM UTC
Category:  None Priority:  5 - Normal
Severity:  6 - Security Status:  Done
Privacy:  Public Assigned to:  jas
Open/Closed:  Closed Operating System:  GNU/Linux
* Mandatory Fields

Add a New Comment Rich Markup

Tue 16 Sep 2008 03:00:18 PM UTC, comment #1: 

Thanks for the report.  This was reported and fixed for 2.4.1, however the problem then wasn't remotely triggered.  I've added a link to this issue to <> for the GNUTLS-SA-2008-2 problem.


Simon Josefsson <jas>
Group administrator
Sun 14 Sep 2008 03:50:44 AM UTC, original submission:  

I'm testing rehandshake processing, and I'm getting segfaults with GnuTLS
2.4.0. Based on the following, it looks to me like hostile TLS servers can make GnuTLS clients corrupt their internal memory, by sending a rehandshake request.

Valgrind's complaint:

==28074== Invalid read of size 4
==28074==    at 0x3B4DE53000: gc_hash_write (gc-libgcrypt.c:431)
==28074==    by 0x3B4DE31020: _gnutls_hash (gnutls_hash_int.c:119)
==28074==    by 0x3B4DE27FA7: _gnutls_send_handshake (gnutls_handshake.c:893)
==28074==    by 0x3B4DE293BB: _gnutls_send_client_hello (gnutls_handshake.c:1861)
==28074==    by 0x3B4DE2B8ED: _gnutls_handshake_client (gnutls_handshake.c:2319)
==28074==    by 0x3B4DE2C687: gnutls_handshake (gnutls_handshake.c:2246)
==28074==    by 0x42026F: x::gnutls::sessionObj::handshake() (sessionobj.C:236)
==28074==    by 0x41FC58: x::gnutls::sessionObj::recv(void*, unsigned long) (sessionobj.C:379)
==28074==    by 0x40CADC: _ZL15testrehandshakev (testsession.C:441)
==28074==    by 0x40E660: main (testsession.C:468)
==28074==  Address 0x64cbce8 is 0 bytes inside a block of size 120 free'd
==28074==    at 0x4A0609F: free (vg_replace_malloc.c:323)
==28074==    by 0x3B4DE2C4A7: _gnutls_handshake_common (gnutls_handshake.c:76)
==28074==    by 0x3B4DE2C631: gnutls_handshake (gnutls_handshake.c:2263)
==28074==    by 0x42026F: x::gnutls::sessionObj::handshake() (sessionobj.C:236)

As far as I can figure out, here's what's happening:

A) Initial handshake.


  if (session->internals.handshake_mac_handle_init == 0)
        /* This branch is taken.
           handshake_mac_handle_md5, handshake_mac_handle_sha are allocated

      session->internals.handshake_mac_handle_init = 1;

// Handshake continues

Eventually, _gnutls_handshake_hash_buffers_clear() gets called, which
deallocates the handshake_mac_handle_md5 and handshake_mac_handle_sha
structures, however, as far as I can tell, handshake_mac_handle_init remains set to 1.

Then, when the client receives a rehandshake request, and follows through,
_gnutls_handshake_hash_init gets called again, and it will NOT allocate the handshake_mac_handle buffers again, and subsequent functions will scribble all over the deallocated memory.

If my analysis is correct here, a hostile TLS server might force memory corruption in TLS clients, by requesting a handshake.

It looks to me like _gnutls_handshake_hash_buffers_clear() should set session->internals.handshake_mac_handle_init=0

Sam Varshavchik <mrsam>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by jas (Posted a comment)
  • -email is unavailable- added by mrsam (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-10-13 jas Open/ClosedOpen Closed
    2008-10-13 jas PrivacyPrivate Public
    2008-09-16 jas StatusNone Done
        Assigned toNone jas

    Back to the top

    Powered by Savane 3.13-b921.
    Corresponding source code