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


sr #106491: Memory corruption in rehandshake

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

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


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>
Project AdministratorIn charge of this item.
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)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    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.7