1. 28 9月, 2016 6 次提交
  2. 27 9月, 2016 6 次提交
  3. 26 9月, 2016 7 次提交
  4. 23 9月, 2016 2 次提交
  5. 22 9月, 2016 17 次提交
    • R
      Add -Wswitch-enum · f3b3d7f0
      Rich Salz 提交于
      Change code so when switching on an enumeration, have case's for all
      enumeration values.
      Reviewed-by: NAndy Polyakov <appro@openssl.org>
      f3b3d7f0
    • M
      Updates CHANGES and NEWS for new release · 39c136cc
      Matt Caswell 提交于
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      39c136cc
    • D
      Avoid KCI attack for GOST · 41b42807
      Dmitry Belyavsky 提交于
      Russian GOST ciphersuites are vulnerable to the KCI attack because they use
      long-term keys to establish the connection when ssl client authorization is
      on. This change brings the GOST implementation into line with the latest
      specs in order to avoid the attack. It should not break backwards
      compatibility.
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      Reviewed-by: NMatt Caswell <matt@openssl.org>
      41b42807
    • M
      Fix a hang with SSL_peek() · b8d24395
      Matt Caswell 提交于
      If while calling SSL_peek() we read an empty record then we go into an
      infinite loop, continually trying to read data from the empty record and
      never making any progress. This could be exploited by a malicious peer in
      a Denial Of Service attack.
      
      CVE-2016-6305
      
      GitHub Issue #1563
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      b8d24395
    • M
      Fix a mem leak in NPN handling · c31dbed7
      Matt Caswell 提交于
      If a server sent multiple NPN extensions in a single ClientHello then a
      mem leak can occur. This will only happen where the client has requested
      NPN in the first place. It does not occur during renegotiation. Therefore
      the maximum that could be leaked in a single connection with a malicious
      server is 64k (the maximum size of the ServerHello extensions section). As
      this is client side, only occurs if NPN has been requested and does not
      occur during renegotiation this is unlikely to be exploitable.
      
      Issue reported by Shi Lei.
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      c31dbed7
    • M
      Add some more OCSP testing · ba881d3b
      Matt Caswell 提交于
      Test that the OCSP callbacks work as expected.
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      ba881d3b
    • M
      Add OCSP_RESPID_match() · a671b3e6
      Matt Caswell 提交于
      Add a function for testing whether a given OCSP_RESPID matches with a
      certificate.
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      a671b3e6
    • M
      Add the ability to set OCSP_RESPID fields · e12c0beb
      Matt Caswell 提交于
      OCSP_RESPID was made opaque in 1.1.0, but no accessors were provided for
      setting the name/key value for the OCSP_RESPID.
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      e12c0beb
    • M
      Fix OCSP Status Request extension unbounded memory growth · e408c09b
      Matt Caswell 提交于
      A malicious client can send an excessively large OCSP Status Request
      extension. If that client continually requests renegotiation,
      sending a large OCSP Status Request extension each time, then there will
      be unbounded memory growth on the server. This will eventually lead to a
      Denial Of Service attack through memory exhaustion. Servers with a
      default configuration are vulnerable even if they do not support OCSP.
      Builds using the "no-ocsp" build time option are not affected.
      
      I have also checked other extensions to see if they suffer from a similar
      problem but I could not find any other issues.
      
      CVE-2016-6304
      
      Issue reported by Shi Lei.
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      e408c09b
    • R
      Fix error message typo, wrong function code · a449b47c
      Richard Levitte 提交于
      Reviewed-by: NMatt Caswell <matt@openssl.org>
      a449b47c
    • M
      Excessive allocation of memory in dtls1_preprocess_fragment() · 48c054fe
      Matt Caswell 提交于
      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: NRichard Levitte <levitte@openssl.org>
      48c054fe
    • M
      Excessive allocation of memory in tls_get_message_header() · c1ef7c97
      Matt Caswell 提交于
      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: NRichard Levitte <levitte@openssl.org>
      c1ef7c97
    • M
      Don't leak on an OPENSSL_realloc() failure · 41bff723
      Matt Caswell 提交于
      If OPENSSL_sk_insert() calls OPENSSL_realloc() and it fails, it was leaking
      the originally allocated memory.
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      41bff723
    • M
      Don't allow too many consecutive warning alerts · af58be76
      Matt Caswell 提交于
      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: NRich Salz <rsalz@openssl.org>
      af58be76
    • A
      rand/randfile.c: treat empty string in RAND_file_name as error. · 7dc0ad4d
      Andy Polyakov 提交于
      Suggested in GH#1589.
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      7dc0ad4d
    • A
      ba8fa4e5
    • A
      rand/randfile.c: restore fallback to $HOME for non-setuid programs. · 799c1293
      Andy Polyakov 提交于
      Reported in GH#1589, but solution is different from suggested.
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      799c1293
  6. 21 9月, 2016 2 次提交