Skip to content
  1. Sep 21, 2016
    • Matt Caswell's avatar
      Excessive allocation of memory in dtls1_preprocess_fragment() · 48c054fe
      Matt Caswell authored
      
      
      This issue is very similar to CVE-2016-6307 described in the previous
      commit. The underlying defect is different but the security analysis and
      impacts are the same except that it impacts DTLS.
      
      A DTLS 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 TLS users.
      
      Issue was reported by Shi Lei (Gear Team, Qihoo 360 Inc.).
      
      CVE-2016-6308
      
      Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      48c054fe
    • Matt Caswell's avatar
      Excessive allocation of memory in tls_get_message_header() · c1ef7c97
      Matt Caswell authored
      
      
      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: default avatarRichard Levitte <levitte@openssl.org>
      c1ef7c97
    • Matt Caswell's avatar
      Don't leak on an OPENSSL_realloc() failure · 41bff723
      Matt Caswell authored
      
      
      If OPENSSL_sk_insert() calls OPENSSL_realloc() and it fails, it was leaking
      the originally allocated memory.
      
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      41bff723
    • Matt Caswell's avatar
      Don't allow too many consecutive warning alerts · af58be76
      Matt Caswell authored
      
      
      Certain warning alerts are ignored if they are received. This can mean that
      no progress will be made if one peer continually sends those warning alerts.
      Implement a count so that we abort the connection if we receive too many.
      
      Issue reported by Shi Lei.
      
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      af58be76
    • Andy Polyakov's avatar
      rand/randfile.c: treat empty string in RAND_file_name as error. · 7dc0ad4d
      Andy Polyakov authored
      
      
      Suggested in GH#1589.
      
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      7dc0ad4d
    • Andy Polyakov's avatar
      ba8fa4e5
    • Andy Polyakov's avatar
      rand/randfile.c: restore fallback to $HOME for non-setuid programs. · 799c1293
      Andy Polyakov authored
      
      
      Reported in GH#1589, but solution is different from suggested.
      
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      799c1293
    • Rich Salz's avatar
      Dcoument -alpn flag · 776e15f9
      Rich Salz authored
      
      
      Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      776e15f9
    • Rich Salz's avatar
      6fcace45
    • Rich Salz's avatar
      Revert "Constify code about X509_VERIFY_PARAM" · 4588cb44
      Rich Salz authored
      This reverts commit 81f9ce1e
      
      .
      
      Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
      4588cb44
    • Richard Levitte's avatar
      test/x509aux.c: Fix argv loop · 780bbb96
      Richard Levitte authored
      
      
      There are cases when argc is more trustable than proper argv termination.
      Since we trust argc in all other test programs, we might as well treat it
      the same way in this program.
      
      Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
      780bbb96
    • Matt Caswell's avatar
    • Matt Caswell's avatar
      Fix a missing NULL check in dsa_builtin_paramgen · 1ff7425d
      Matt Caswell authored
      
      
      We should check the last BN_CTX_get() call to ensure that it isn't NULL
      before we try and use any of the allocated BIGNUMs.
      
      Issue reported by Shi Lei.
      
      Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      1ff7425d
    • Richard Levitte's avatar
      VMS: add [.util]shlib_wrap.exe and its build instructions · f3ff481f
      Richard Levitte authored
      
      
      This is a program for VMS that corresponds to util/shlib_wrap.sh.
      
      Reviewed-by: default avatarRich Salz <rsalz@openssl.org>
      f3ff481f
    • Richard Levitte's avatar
  2. Sep 20, 2016
  3. Sep 19, 2016
  4. Sep 18, 2016