Skip to content


Browse files Browse the repository at this point in the history
Excessive allocation of memory in tls_get_message_header()
A TLS message includes 3 bytes for its length in the header for the message.
This would allow for messages up to 16Mb in length. Messages of this length
are excessive and OpenSSL includes a check to ensure that a peer is sending
reasonably sized messages in order to avoid too much memory being consumed
to service a connection. A flaw in the logic of version 1.1.0 means that
memory for the message is allocated too early, prior to the excessive
message length check. Due to way memory is allocated in OpenSSL this could
mean an attacker could force up to 21Mb to be allocated to service a
connection. This could lead to a Denial of Service through memory
exhaustion. However, the excessive message length check still takes place,
and this would cause the connection to immediately fail. Assuming that the
application calls SSL_free() on the failed conneciton in a timely manner
then the 21Mb of allocated memory will then be immediately freed again.
Therefore the excessive memory allocation will be transitory in nature.
This then means that there is only a security impact if:

1) The application does not call SSL_free() in a timely manner in the
event that the connection fails
2) The application is working in a constrained environment where there
is very little free memory
3) The attacker initiates multiple connection attempts such that there
are multiple connections in a state where memory has been allocated for
the connection; SSL_free() has not yet been called; and there is
insufficient memory to service the multiple requests.

Except in the instance of (1) above any Denial Of Service is likely to
be transitory because as soon as the connection fails the memory is
subsequently freed again in the SSL_free() call. However there is an
increased risk during this period of application crashes due to the lack
of memory - which would then mean a more serious Denial of Service.

This issue does not affect DTLS users.

Issue was reported by Shi Lei (Gear Team, Qihoo 360 Inc.).


Reviewed-by: Richard Levitte <>
(cherry picked from commit c1ef7c9)
  • Loading branch information
mattcaswell committed Sep 21, 2016
1 parent f757ce2 commit 4b390b6
Show file tree
Hide file tree
Showing 2 changed files with 11 additions and 10 deletions.
11 changes: 11 additions & 0 deletions ssl/statem/statem.c
Expand Up @@ -542,6 +542,17 @@ static SUB_STATE_RETURN read_state_machine(SSL *s)

/* dtls_get_message already did this */
if (!SSL_IS_DTLS(s)
&& s->s3->tmp.message_size > 0
&& !BUF_MEM_grow_clean(s->init_buf,
ssl3_send_alert(s, SSL3_AL_FATAL, SSL_AD_INTERNAL_ERROR);

st->read_state = READ_STATE_BODY;
/* Fall through */

Expand Down
10 changes: 0 additions & 10 deletions ssl/statem/statem_lib.c
Expand Up @@ -414,10 +414,6 @@ int tls_get_message_header(SSL *s, int *mt)
l = RECORD_LAYER_get_rrec_length(&s->rlayer)
if (l && !BUF_MEM_grow_clean(s->init_buf, (int)l)) {
goto err;
s->s3->tmp.message_size = l;

s->init_msg = s->init_buf->data;
Expand All @@ -430,11 +426,6 @@ int tls_get_message_header(SSL *s, int *mt)
goto f_err;
if (l && !BUF_MEM_grow_clean(s->init_buf,
(int)l + SSL3_HM_HEADER_LENGTH)) {
goto err;
s->s3->tmp.message_size = l;

s->init_msg = s->init_buf->data + SSL3_HM_HEADER_LENGTH;
Expand All @@ -444,7 +435,6 @@ int tls_get_message_header(SSL *s, int *mt)
return 1;
ssl3_send_alert(s, SSL3_AL_FATAL, al);
return 0;

Expand Down

0 comments on commit 4b390b6

Please sign in to comment.