1. 31 10月, 2017 9 次提交
  2. 30 10月, 2017 8 次提交
  3. 27 10月, 2017 1 次提交
  4. 26 10月, 2017 7 次提交
  5. 25 10月, 2017 3 次提交
  6. 24 10月, 2017 1 次提交
    • M
      Don't make any changes to the lhash structure if we are going to fail · 4ce8bebc
      Matt Caswell 提交于
      The lhash expand() function can fail if realloc fails. The previous
      implementation made changes to the structure and then attempted to do a
      realloc. If the realloc failed then it attempted to undo the changes it
      had just made. Unfortunately changes to lh->p were not undone correctly,
      ultimately causing subsequent expand() calls to increment num_nodes to a
      value higher than num_alloc_nodes, which can cause out-of-bounds reads/
      writes. This is not considered a security issue because an attacker cannot
      cause realloc to fail.
      
      This commit moves the realloc call to near the beginning of the function
      before any other changes are made to the lhash structure. That way if a
      failure occurs we can immediately fail without having to undo anything.
      
      Thanks to Pavel Kopyl (Samsung) for reporting this issue.
      Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de>
      Reviewed-by: NViktor Dukhovni <viktor@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/4550)
      4ce8bebc
  7. 23 10月, 2017 5 次提交
  8. 21 10月, 2017 2 次提交
  9. 20 10月, 2017 1 次提交
  10. 19 10月, 2017 1 次提交
  11. 18 10月, 2017 2 次提交
    • K
      Remove parentheses of return. · 26a7d938
      KaoruToda 提交于
      Since return is inconsistent, I removed unnecessary parentheses and
      unified them.
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      Reviewed-by: NMatt Caswell <matt@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/4541)
      26a7d938
    • B
      Add missing RAND_DRBG locking · 2139145b
      Benjamin Kaduk 提交于
      The drbg's lock must be held across calls to RAND_DRBG_generate()
      to prevent simultaneous modification of internal state.
      
      This was observed in practice with simultaneous SSL_new() calls attempting
      to seed the (separate) per-SSL RAND_DRBG instances from the global
      rand_drbg instance; this eventually led to simultaneous calls to
      ctr_BCC_update() attempting to increment drbg->bltmp_pos for their
      respective partial final block, violating the invariant that bltmp_pos < 16.
      The AES operations performed in ctr_BCC_blocks() makes the race window
      quite easy to trigger.  A value of bltmp_pos greater than 16 induces
      catastrophic failure in ctr_BCC_final(), with subtraction overflowing
      and leading to an attempt to memset() to zero a very large range,
      which eventually reaches an unmapped page and segfaults.
      
      Provide the needed locking in get_entropy_from_parent(), as well as
      fixing a similar issue in RAND_priv_bytes().  There is also an
      unlocked call to RAND_DRBG_generate() in ssl_randbytes(), but the
      requisite serialization is already guaranteed by the requirements on
      the application's usage of SSL objects, and no further locking is
      needed for correct behavior.  In that case, leave a comment noting
      the apparent discrepancy and the reason for its safety (at present).
      Reviewed-by: NPaul Dale <paul.dale@oracle.com>
      Reviewed-by: NKurt Roeckx <kurt@roeckx.be>
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/4328)
      2139145b