Skip to content
  1. Feb 22, 2019
    • Richard Levitte's avatar
      Windows: Call TerminateProcess, not ExitProcess · 4af54c9b
      Richard Levitte authored
      Ty Baen-Price explains:
      
      > Problem and Resolution:
      > The following lines of code make use of the Microsoft API ExitProcess:
      >
      > ```
      > Apps\Speed.c line 335:	ExitProcess(ret);
      > Ms\uplink.c line 22: ExitProcess(1);
      > ```
      >
      > These function calls are made after fatal errors are detected and
      > program termination is desired. ExitProcess(), however causes
      > _orderly_ shutdown of a process and all its threads, i.e. it unloads
      > all dlls and runs all destructors. See MSDN for details of exactly
      > what happens
      > (https://msdn.microsoft.com/en-us/library/windows/desktop/ms682658(v=vs.85).aspx
      
      ).
      > The MSDN page states that ExitProcess should never be called unless
      > it is _known to be safe_ to call it. These calls should simply be
      > replaced with calls to TerminateProcess(), which is what should be
      > called for _disorderly_ shutdown.
      >
      > An example of usage:
      >
      > ```
      > TerminateProcess(GetCurrentProcess(), exitcode);
      > ```
      >
      > Effect of Problem:
      > Because of a compilation error (wrong c++ runtime), my program
      > executed the uplink.c ExitProcess() call. This caused the single
      > OpenSSL thread to start executing the destructors of all my dlls,
      > and their objects. Unfortunately, about 30 other threads were
      > happily using those objects at that time, eventually causing a
      > 0xC0000005 ACCESS_VIOLATION. Obviously an ACCESS_VIOLATION is the
      > best case scenario, as I'm sure you can imagine at the consequences
      > of undiscovered memory corruption, even in a terminating process.
      
      And on the subject of `TerminateProcess()` being asynchronous:
      
      > That is technically true, but I think it's probably synchronous
      > "enough" for your purposes, since a call to TerminateProcess
      > suspends execution of all threads in the target process. This means
      > it's really only asynchronous if you're calling TerminateProcess one
      > some _other_ process. If you're calling TerminateProcess on your own
      > process, you'll never return from the TerminateProcess call.
      
      Fixes #2489
      Was originally RT-4526
      
      Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/8301)
      
      (cherry picked from commit 92579599)
      4af54c9b
    • Matt Caswell's avatar
      Don't restrict the number of KeyUpdate messages we can process · f6d64b51
      Matt Caswell authored
      
      
      Prior to this commit we were keeping a count of how many KeyUpdates we
      have processed and failing if we had had too many. This simplistic approach
      is not sufficient for long running connections. Since many KeyUpdates
      would not be a particular good DoS route anyway, the simplest solution is
      to simply remove the key update count.
      
      Fixes #8068
      
      Reviewed-by: default avatarKurt Roeckx <kurt@roeckx.be>
      (Merged from https://github.com/openssl/openssl/pull/8299)
      
      (cherry picked from commit 3409a5ff8a44ddaf043d83ed22e657ae871be289)
      f6d64b51
    • Dr. Matthias St. Pierre's avatar
      engines/dasync: add explaining comments about AES-128-CBC-HMAC-SHA1 · 4a81b8b6
      Dr. Matthias St. Pierre authored
      
      
      Fixes #7950
      
      It was reported that there might be a null pointer dereference in the
      implementation of the dasync_aes_128_cbc_hmac_sha1() cipher, because
      EVP_aes_128_cbc_hmac_sha1() can return a null pointer if AES-NI is
      not available. It took some analysis to find out that this is not
      an issue in practice, and these comments explain the reason to comfort
      further NPD hunters.
      
      Detected by GitHub user @wurongxin1987 using the Sourcebrella Pinpoint
      static analyzer.
      
      Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/8305)
      
      (cherry picked from commit a4a0a1eb)
      4a81b8b6
    • Paul Yang's avatar
      Fix a grammar nit in CRYPTO_get_ex_new_index.pod · d600f3d3
      Paul Yang authored
      
      
      Reviewed-by: default avatarPaul Dale <paul.dale@oracle.com>
      (Merged from https://github.com/openssl/openssl/pull/8303)
      
      (cherry picked from commit 84712024da5e5485e8397afc763555355bddf960)
      d600f3d3
  2. Feb 21, 2019
  3. Feb 20, 2019
    • Nicola Tuveri's avatar
      Clear BN_FLG_CONSTTIME on BN_CTX_get() · e2e69dce
      Nicola Tuveri authored
      
      
      (cherry picked from commit c8147d37ccaaf28c430d3fb45a14af36597e48b8)
      
      Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/8253)
      e2e69dce
    • Nicola Tuveri's avatar
      Test for constant-time flag leakage in BN_CTX · 3c97136e
      Nicola Tuveri authored
      This commit adds a simple unit test to make sure that the constant-time
      flag does not "leak" among BN_CTX frames:
      
      - test_ctx_consttime_flag() initializes (and later frees before
        returning) a BN_CTX object, then it calls in sequence
        test_ctx_set_ct_flag() and test_ctx_check_ct_flag() using the same
        BN_CTX object. The process is run twice, once with a "normal"
        BN_CTX_new() object, then with a BN_CTX_secure_new() one.
      - test_ctx_set_ct_flag() starts a frame in the given BN_CTX and sets the
        BN_FLG_CONSTTIME flag on some of the BIGNUMs obtained from the frame
        before ending it.
      - test_ctx_check_ct_flag() then starts a new frame and gets a number of
        BIGNUMs from it. In absence of leaks, none of the BIGNUMs in the new
        frame should have BN_FLG_CONSTTIME set.
      
      In actual BN_CTX usage inside libcrypto the leak could happen at any
      depth level in the BN_CTX stack, with varying results depending on the
      patterns of sibling trees of nested function calls sharing the same
      BN_CTX object, and the effect of unintended BN_FLG_CONSTTIME on the
      called BN_* functions.
      
      This simple unit test abstracts away this complexity and verifies that
      the leak does not happen between two sibling functions sharing the same
      BN_CTX object at the same level of nesting.
      
      (cherry picked from commit fe16ae5f
      
      )
      
      Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/8253)
      3c97136e
    • Billy Brumley's avatar
      [test] unit test for field_inv function pointer in EC_METHOD · d11e4bcd
      Billy Brumley authored
      
      
      (cherry picked from commit 8f58ede09572dcc6a7e6c01280dd348240199568)
      
      Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
      Reviewed-by: default avatarNicola Tuveri <nic.tuv@gmail.com>
      (Merged from https://github.com/openssl/openssl/pull/8262)
      d11e4bcd
    • Billy Brumley's avatar
      SCA hardening for mod. field inversion in EC_GROUP · 48e82c8e
      Billy Brumley authored
      
      
      This commit adds a dedicated function in `EC_METHOD` to access a modular
      field inversion implementation suitable for the specifics of the
      implemented curve, featuring SCA countermeasures.
      
      The new pointer is defined as:
      `int (*field_inv)(const EC_GROUP*, BIGNUM *r, const BIGNUM *a, BN_CTX*)`
      and computes the multiplicative inverse of `a` in the underlying field,
      storing the result in `r`.
      
      Three implementations are included, each including specific SCA
      countermeasures:
        - `ec_GFp_simple_field_inv()`, featuring SCA hardening through
          blinding.
        - `ec_GFp_mont_field_inv()`, featuring SCA hardening through Fermat's
          Little Theorem (FLT) inversion.
        - `ec_GF2m_simple_field_inv()`, that uses `BN_GF2m_mod_inv()` which
          already features SCA hardening through blinding.
      
      From a security point of view, this also helps addressing a leakage
      previously affecting conversions from projective to affine coordinates.
      
      This commit also adds a new error reason code (i.e.,
      `EC_R_CANNOT_INVERT`) to improve consistency between the three
      implementations as all of them could fail for the same reason but
      through different code paths resulting in inconsistent error stack
      states.
      
      Co-authored-by: default avatarNicola Tuveri <nic.tuv@gmail.com>
      
      (cherry picked from commit e0033efc
      
      )
      
      Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
      Reviewed-by: default avatarNicola Tuveri <nic.tuv@gmail.com>
      (Merged from https://github.com/openssl/openssl/pull/8262)
      48e82c8e
  4. Feb 19, 2019
  5. Feb 18, 2019
  6. Feb 17, 2019
  7. Feb 15, 2019
  8. Feb 14, 2019
    • Matt Caswell's avatar
      Fix -verify_return_error in s_client · 9c931841
      Matt Caswell authored
      
      
      The "verify_return_error" option in s_client is documented as:
      
       Return verification errors instead of continuing. This will typically
       abort the handshake with a fatal error.
      
      In practice this option was ignored unless also accompanied with the
      "-verify" option. It's unclear what the original intention was. One fix
      could have been to change the documentation to match the actual behaviour.
      However it seems unecessarily complex and unexpected that you should need
      to have both options. Instead the fix implemented here is make the option
      match the documentation so that "-verify" is not also required.
      
      Note that s_server has a similar option where "-verify" (or "-Verify") is
      still required. This makes more sense because those options additionally
      request a certificate from the client. Without a certificate there is no
      possibility of a verification failing, and so "-verify_return_error" doing
      nothing seems ok.
      
      Fixes #8079
      
      Reviewed-by: default avatarNicola Tuveri <nic.tuv@gmail.com>
      (Merged from https://github.com/openssl/openssl/pull/8080)
      
      (cherry picked from commit 78021171dbcb05ddab1b5daffbfc62504ea709a4)
      9c931841
    • Matt Caswell's avatar
      Don't signal SSL_CB_HANDSHAKE_START for TLSv1.3 post-handshake messages · 37857e9b
      Matt Caswell authored
      
      
      The original 1.1.1 design was to use SSL_CB_HANDSHAKE_START and
      SSL_CB_HANDSHAKE_DONE to signal start/end of a post-handshake message
      exchange in TLSv1.3. Unfortunately experience has shown that this confuses
      some applications who mistake it for a TLSv1.2 renegotiation. This means
      that KeyUpdate messages are not handled properly.
      
      This commit removes the use of SSL_CB_HANDSHAKE_START and
      SSL_CB_HANDSHAKE_DONE to signal the start/end of a post-handshake
      message exchange. Individual post-handshake messages are still signalled in
      the normal way.
      
      This is a potentially breaking change if there are any applications already
      written that expect to see these TLSv1.3 events. However, without it,
      KeyUpdate is not currently usable for many applications.
      
      Fixes #8069
      
      Reviewed-by: default avatarRichard Levitte <levitte@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/8096)
      
      (cherry picked from commit 4af5836b)
      37857e9b
    • Sam Roberts's avatar
      Ignore cipher suites when setting cipher list · 1c31fe7e
      Sam Roberts authored
      
      
      set_cipher_list() sets TLSv1.2 (and below) ciphers, and its success or
      failure should not depend on whether set_ciphersuites() has been used to
      setup TLSv1.3 ciphers.
      
      Reviewed-by: default avatarPaul Dale <paul.dale@oracle.com>
      Reviewed-by: default avatarBen Kaduk <kaduk@mit.edu>
      Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/7759)
      
      (cherry picked from commit 3c83c5ba4f6502c708b7a5f55c98a10e312668da)
      1c31fe7e
    • Richard Levitte's avatar
      Configure: stop forcing use of DEFINE macros in headers · cd272eee
      Richard Levitte authored
      
      
      There are times when one might want to use something like
      DEFINE_STACK_OF in a .c file, because it defines a stack for a type
      defined in that .c file.  Unfortunately, when configuring with
      `--strict-warnings`, clang aggressively warn about unused functions in
      such cases, which forces the use of such DEFINE macros to header
      files.
      
      We therefore disable this warning from the `--strict-warnings`
      definition for clang.
      
      (note for the curious: `-Wunused-function` is enabled via `-Wall`)
      
      Reviewed-by: default avatarPaul Dale <paul.dale@oracle.com>
      (Merged from https://github.com/openssl/openssl/pull/8234)
      
      (cherry picked from commit f11ffa50)
      cd272eee
  9. Feb 13, 2019
  10. Feb 11, 2019
  11. Feb 10, 2019
  12. Feb 08, 2019
  13. Feb 07, 2019
  14. Feb 05, 2019
  15. Feb 04, 2019