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

 
 

sr #106491: Memory corruption in rehandshake

Submitted by:  Sam Varshavchik <mrsam>
Submitted on:  Sun Sep 14 03:50:44 2008  
 
Category: NonePriority: 5 - Normal
Severity: 6 - SecurityStatus: Done
Privacy: PublicAssigned to: Simon Josefsson <jas>
Open/Closed: ClosedOperating System: GNU/Linux

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

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

 

Tue Sep 16 15:00:18 2008, 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 <http://www.gnu.org/software/gnutls/security.html> for the GNUTLS-SA-2008-2 problem.

Thanks,
Simon

Simon Josefsson <jas>
Project AdministratorIn charge of this item.
Sun Sep 14 03:50:44 2008, 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.

_gnutls_handshake_hash_init:

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 File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

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

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon Oct 13 13:56:46 2008jasOpen/ClosedOpen=>Closed
    Mon Oct 13 13:52:23 2008jasPrivacyPrivate=>Public
    Tue Sep 16 15:00:17 2008jasStatusNone=>Done
      Assigned toNone=>jas

    Back to the top


    Powered by Savane 3.1-cleanup1