Add a New Comment (Rich Markup)
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
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
(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)
Attach Files: Comment:
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
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.
Please enter the title of George Orwell's famous dystopian book (it's a date):
Follow 4 latest changes.
Copyright © 2023 Free Software Foundation, Inc. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team. Source Code
Powered by Savane 3.11