Bug 999669 (CVE-2016-6307) - VUL-0: CVE-2016-6307: openssl: Excessive allocation of memory in tls_get_message_header()
Summary: VUL-0: CVE-2016-6307: openssl: Excessive allocation of memory in tls_get_mess...
Status: RESOLVED UPSTREAM
Alias: CVE-2016-6307
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents (show other bugs)
Version: unspecified
Hardware: Other Other
: P3 - Medium : Minor
Target Milestone: ---
Assignee: Security Team bot
QA Contact: Security Team bot
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 999665
  Show dependency treegraph
 
Reported: 2016-09-19 13:14 UTC by Alexander Bergmann
Modified: 2016-09-22 11:03 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Comment 2 Swamp Workflow Management 2016-09-19 22:01:13 UTC
bugbot adjusting priority
Comment 3 Vítězslav Čížek 2016-09-20 09:24:49 UTC
The problem appeared in openssl after the state machine rewrite, so >= 1.1.0.
None of our distributions are affected.
Comment 5 Marcus Meissner 2016-09-22 11:02:54 UTC
in git

commit 4b390b6c3f8df925dc92a3dd6b022baa9a2f4650
Author: Matt Caswell <matt@openssl.org>
Date:   Mon Sep 19 11:39:21 2016 +0100

    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
    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.
    
    Issue was reported by Shi Lei (Gear Team, Qihoo 360 Inc.).
    
    CVE-2016-6307
    
    Reviewed-by: Richard Levitte <levitte@openssl.org>
    (cherry picked from commit c1ef7c971d0bbf117c3c80f65b5875e2e7b024b1)
Comment 6 Marcus Meissner 2016-09-22 11:03:19 UTC
we are not shipping openssl 1.1 yet, so we are not affected.