1. 03 9月, 2015 1 次提交
  2. 02 9月, 2015 1 次提交
    • V
      Better handling of verify param id peername field · a0724ef1
      Viktor Dukhovni 提交于
      Initialize pointers in param id by the book (explicit NULL assignment,
      rather than just memset 0).
      
      In x509_verify_param_zero() set peername to NULL after freeing it.
      
      In x509_vfy.c's internal check_hosts(), avoid potential leak of
      possibly already non-NULL peername.  This is only set when a check
      succeeds, so don't need to do this repeatedly in the loop.
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      a0724ef1
  3. 01 9月, 2015 5 次提交
  4. 28 8月, 2015 1 次提交
  5. 14 8月, 2015 1 次提交
  6. 12 8月, 2015 1 次提交
  7. 11 8月, 2015 1 次提交
  8. 08 7月, 2015 3 次提交
    • M
      Extend -show_chain option to verify to show more info · 7f3f41d8
      Matt Caswell 提交于
      The -show_chain flag to the verify command line app shows information about
      the chain that has been built. This commit adds the text "untrusted" against
      those certificates that have been used from the untrusted list.
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      7f3f41d8
    • M
      Reject calls to X509_verify_cert that have not been reinitialised · aae41f8c
      Matt Caswell 提交于
      The function X509_verify_cert checks the value of |ctx->chain| at the
      beginning, and if it is NULL then it initialises it, along with the value
      of ctx->untrusted. The normal way to use X509_verify_cert() is to first
      call X509_STORE_CTX_init(); then set up various parameters etc; then call
      X509_verify_cert(); then check the results; and finally call
      X509_STORE_CTX_cleanup(). The initial call to X509_STORE_CTX_init() sets
      |ctx->chain| to NULL. The only place in the OpenSSL codebase  where
      |ctx->chain| is set to anything other than a non NULL value is in
      X509_verify_cert itself. Therefore the only ways that |ctx->chain| could be
      non NULL on entry to X509_verify_cert is if one of the following occurs:
      1) An application calls X509_verify_cert() twice without re-initialising
      in between.
      2) An application reaches inside the X509_STORE_CTX structure and changes
      the value of |ctx->chain| directly.
      
      With regards to the second of these, we should discount this - it should
      not be supported to allow this.
      
      With regards to the first of these, the documentation is not exactly
      crystal clear, but the implication is that you must call
      X509_STORE_CTX_init() before each call to X509_verify_cert(). If you fail
      to do this then, at best, the results would be undefined.
      
      Calling X509_verify_cert() with |ctx->chain| set to a non NULL value is
      likely to have unexpected results, and could be dangerous. This commit
      changes the behaviour of X509_verify_cert() so that it causes an error if
      |ctx->chain| is anything other than NULL (because this indicates that we
      have not been initialised properly). It also clarifies the associated
      documentation. This is a follow up commit to CVE-2015-1793.
      Reviewed-by: NStephen Henson <steve@openssl.org>
      aae41f8c
    • M
      Fix alternate chains certificate forgery issue · 2aacec8f
      Matt Caswell 提交于
      During certificate verfification, OpenSSL will attempt to find an
      alternative certificate chain if the first attempt to build such a chain
      fails. An error in the implementation of this logic can mean that an
      attacker could cause certain checks on untrusted certificates to be
      bypassed, such as the CA flag, enabling them to use a valid leaf
      certificate to act as a CA and "issue" an invalid certificate.
      
      This occurs where at least one cert is added to the first chain from the
      trust store, but that chain still ends up being untrusted. In that case
      ctx->last_untrusted is decremented in error.
      
      Patch provided by the BoringSSL project.
      
      CVE-2015-1793
      Reviewed-by: NStephen Henson <steve@openssl.org>
      2aacec8f
  9. 11 6月, 2015 1 次提交
  10. 29 5月, 2015 1 次提交
  11. 23 5月, 2015 1 次提交
    • R
      Fix the update target and remove duplicate file updates · 0f539dc1
      Richard Levitte 提交于
      We had updates of certain header files in both Makefile.org and the
      Makefile in the directory the header file lived in.  This is error
      prone and also sometimes generates slightly different results (usually
      just a comment that differs) depending on which way the update was
      done.
      
      This removes the file update targets from the top level Makefile, adds
      an update: target in all Makefiles and has it depend on the depend: or
      local_depend: targets, whichever is appropriate, so we don't get a
      double run through the whole file tree.
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      0f539dc1
  12. 21 5月, 2015 1 次提交
  13. 14 5月, 2015 2 次提交
  14. 11 5月, 2015 1 次提交
  15. 06 5月, 2015 2 次提交
    • G
      Initialize potentially uninitialized local variables · 4c9b0a03
      Gunnar Kudrjavets 提交于
      Compiling OpenSSL code with MSVC and /W4 results in a number of warnings.
      One category of warnings is particularly interesting - C4701 (potentially
      uninitialized local variable 'name' used). This warning pretty much means
      that there's a code path which results in uninitialized variables being used
      or returned. Depending on compiler, its options, OS, values in registers
      and/or stack, the results can be nondeterministic. Cases like this are very
      hard to debug so it's rational to fix these issues.
      
      This patch contains a set of trivial fixes for all the C4701 warnings (just
      initializing variables to 0 or NULL or appropriate error code) to make sure
      that deterministic values will be returned from all the execution paths.
      
      RT#3835
      Signed-off-by: NMatt Caswell <matt@openssl.org>
      
      Matt's note: All of these appear to be bogus warnings, i.e. there isn't
      actually a code path where an unitialised variable could be used - its just
      that the compiler hasn't been able to figure that out from the logic. So
      this commit is just about silencing spurious warnings.
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      4c9b0a03
    • R
      memset, memcpy, sizeof consistency fixes · 16f8d4eb
      Rich Salz 提交于
      Just as with the OPENSSL_malloc calls, consistently use sizeof(*ptr)
      for memset and memcpy.  Remove needless casts for those functions.
      For memset, replace alternative forms of zero with 0.
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      16f8d4eb
  16. 05 5月, 2015 1 次提交
    • R
      Use safer sizeof variant in malloc · b4faea50
      Rich Salz 提交于
      For a local variable:
              TYPE *p;
      Allocations like this are "risky":
              p = OPENSSL_malloc(sizeof(TYPE));
      if the type of p changes, and the malloc call isn't updated, you
      could get memory corruption.  Instead do this:
              p = OPENSSL_malloc(sizeof(*p));
      Also fixed a few memset() calls that I noticed while doing this.
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      b4faea50
  17. 04 5月, 2015 1 次提交
  18. 03 5月, 2015 1 次提交
  19. 02 5月, 2015 4 次提交
  20. 01 5月, 2015 2 次提交
  21. 30 4月, 2015 1 次提交
    • R
      free NULL cleanup 8 · 2ace7450
      Rich Salz 提交于
      Do not check for NULL before calling a free routine.  This addresses:
          ASN1_BIT_STRING_free ASN1_GENERALIZEDTIME_free ASN1_INTEGER_free
          ASN1_OBJECT_free ASN1_OCTET_STRING_free ASN1_PCTX_free ASN1_SCTX_free
          ASN1_STRING_clear_free ASN1_STRING_free ASN1_TYPE_free
          ASN1_UTCTIME_free M_ASN1_free_of
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      2ace7450
  22. 29 4月, 2015 1 次提交
  23. 12 4月, 2015 1 次提交
  24. 01 4月, 2015 2 次提交
  25. 28 3月, 2015 2 次提交
  26. 25 3月, 2015 1 次提交