Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1378203 - (CVE-2016-6307) CVE-2016-6307 openssl: excessive allocation of memory in tls_get_message_header()
CVE-2016-6307 openssl: excessive allocation of memory in tls_get_message_head...
Status: CLOSED NOTABUG
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
impact=low,public=20160921,reported=2...
: Security
Depends On:
Blocks: 1367347
  Show dependency treegraph
 
Reported: 2016-09-21 16:04 EDT by Tomas Hoger
Modified: 2016-11-08 11:01 EST (History)
1 user (show)

See Also:
Fixed In Version: openssl 1.1.0a
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-09-21 16:07:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tomas Hoger 2016-09-21 16:04:45 EDT
Quoting form the draft of the OpenSSL upstream advisory:

Excessive allocation of memory in tls_get_message_header() (CVE-2016-6307)
==========================================================================

Severity: Low

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
or
2) The application is working in a constrained environment where there
is very little free memory
or
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.

OpenSSL 1.1.0 TLS users should upgrade to 1.1.0a

This issue was reported to OpenSSL on 18th September 2016 by Shi Lei (Gear Team,
Qihoo 360 Inc.). The fix was developed by Matt Caswell of the OpenSSL
development team.
Comment 1 Tomas Hoger 2016-09-21 16:04:53 EDT
Acknowledgments:

Name: the OpenSSL project
Upstream: Shi Lei (Gear Team of Qihoo 360 Inc.)
Comment 3 Tomas Hoger 2016-09-21 16:07:18 EDT
This issue only affected OpenSSL 1.1.0, which is not yet part of any Red Hat product.
Comment 4 Adam Mariš 2016-09-22 11:14:31 EDT
External References:

https://www.openssl.org/news/secadv/20160922.txt
Comment 5 Tomas Hoger 2016-09-26 06:38:52 EDT
The fix for this issue introduced more severe use after free problem - see CVE-2016-6309 / bug 1379302.

Note You need to log in before you can comment on or make changes to this bug.