1. 26 2月, 2019 10 次提交
  2. 23 2月, 2019 3 次提交
    • R
      Windows: Call TerminateProcess, not ExitProcess · 4af54c9b
      Richard Levitte 提交于
      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: NMatt Caswell <matt@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/8301)
      
      (cherry picked from commit 925795995018bddb053e863db8b5c52d2a9005d9)
      4af54c9b
    • M
      Don't restrict the number of KeyUpdate messages we can process · f6d64b51
      Matt Caswell 提交于
      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: NKurt Roeckx <kurt@roeckx.be>
      (Merged from https://github.com/openssl/openssl/pull/8299)
      
      (cherry picked from commit 3409a5ff8a44ddaf043d83ed22e657ae871be289)
      f6d64b51
    • D
      engines/dasync: add explaining comments about AES-128-CBC-HMAC-SHA1 · 4a81b8b6
      Dr. Matthias St. Pierre 提交于
      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: NMatt Caswell <matt@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/8305)
      
      (cherry picked from commit a4a0a1eb43cfccd128d085932a567e0482fbfe47)
      4a81b8b6
  3. 22 2月, 2019 1 次提交
  4. 21 2月, 2019 6 次提交
  5. 20 2月, 2019 1 次提交
  6. 19 2月, 2019 4 次提交
  7. 18 2月, 2019 4 次提交
  8. 15 2月, 2019 4 次提交
    • R
      Mark generated functions unused (applies to safestack, lhash, sparse_array) · ed48d203
      Richard Levitte 提交于
      safestack.h, lhash.h and sparse_array.h all define macros to generate
      a full API for the containers as static inline functions.  This
      potentially generates unused code, which some compilers may complain
      about.
      
      We therefore need to mark those generated functions as unused, so the
      compiler knows that we know, and stops complaining about it.
      Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com>
      (Merged from https://github.com/openssl/openssl/pull/8246)
      
      (cherry picked from commit 48fe4ce104df060dd5d2b4188a56eb554d94d819)
      ed48d203
    • M
      Use order not degree to calculate a buffer size in ecdsatest · 1b25dc0c
      Matt Caswell 提交于
      Otherwise this can result in an incorrect calculation of the maximum
      encoded integer length, meaning an insufficient buffer size is allocated.
      
      Thanks to Billy Brumley for helping to track this down.
      
      Fixes #8209
      Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com>
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      Reviewed-by: NPaul Dale <paul.dale@oracle.com>
      (Merged from https://github.com/openssl/openssl/pull/8237)
      
      (cherry picked from commit 9fc8f18f59f4a4c853466dca64a23b8af681bf1c)
      1b25dc0c
    • M
      Fix -verify_return_error in s_client · 9c931841
      Matt Caswell 提交于
      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: NNicola Tuveri <nic.tuv@gmail.com>
      (Merged from https://github.com/openssl/openssl/pull/8080)
      
      (cherry picked from commit 78021171dbcb05ddab1b5daffbfc62504ea709a4)
      9c931841
    • M
      Don't signal SSL_CB_HANDSHAKE_START for TLSv1.3 post-handshake messages · 37857e9b
      Matt Caswell 提交于
      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: NRichard Levitte <levitte@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/8096)
      
      (cherry picked from commit 4af5836b55442f31795eff6c8c81ea7a1b8cf94b)
      37857e9b
  9. 14 2月, 2019 3 次提交
  10. 13 2月, 2019 2 次提交
  11. 11 2月, 2019 2 次提交