Skip to content
  1. Feb 28, 2019
  3. Feb 27, 2019
  5. Feb 26, 2019
  7. Feb 25, 2019
    • Richard Levitte's avatar
      Rearrange the inclusion of curve448/curve448_lcl.h · f408e2a3
      Richard Levitte authored 
      

The real cause for this change is that test/ec_internal_test.c
includes ec_lcl.h, and including curve448/curve448_lcl.h from there
doesn't work so well with compilers who always do inclusions relative
to the C file being compiled.

Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8334)
      f408e2a3
    • Matt Caswell's avatar
      Ensure bn_cmp_words can handle the case where n == 0 · df2cb82a
      Matt Caswell authored 
      

Thanks to David Benjamin who reported this, performed the analysis and
suggested the patch. I have incorporated some of his analysis in the
comments below.

This issue can cause an out-of-bounds read. It is believed that this was
not reachable until the recent "fixed top" changes. Analysis has so far
only identified one code path that can encounter this - although it is
possible that others may be found. The one code path only impacts 1.0.2 in
certain builds. The fuzzer found a path in RSA where iqmp is too large. If
the input is all zeros, the RSA CRT logic will multiply a padded zero by
iqmp. Two mitigating factors:

- Private keys which trip this are invalid (iqmp is not reduced mod p).
Only systems which take untrusted private keys care.
- In OpenSSL 1.1.x, there is a check which rejects the oversize iqmp,
so the bug is only reproducible in 1.0.2 so far.

Fortunately, the bug appears to be relatively harmless. The consequences of
bn_cmp_word's misbehavior are:

- OpenSSL may crash if the buffers are page-aligned and the previous page is
non-existent.
- OpenSSL will incorrectly treat two BN_ULONG buffers as not equal when they
are equal.
- Side channel concerns.

The first is indeed a concern and is a DoS bug. The second is fine in this
context. bn_cmp_word and bn_cmp_part_words are used to compute abs(a0 - a1)
in Karatsuba. If a0 = a1, it does not matter whether we use a0 - a1 or
a1 - a0. The third would be worth thinking about, but it is overshadowed
by the entire Karatsuba implementation not being constant time.

Due to the difficulty of tripping this and the low impact no CVE is felt
necessary for this issue.

Reviewed-by: default avatarPaul Dale <paul.dale@oracle.com>
Reviewed-by: default avatarViktor Dukhovni <viktor@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8326)

(cherry picked from commit 576129cd)
      df2cb82a
  9. 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 925795995018bddb053e863db8b5c52d2a9005d9)
      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 84712024)
      d600f3d3
  11. Feb 21, 2019
  13. 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 8f58ede0

)

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 e0033efc30b0f00476bba8f0fa5512be5dc8a3f1)

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
  15. Feb 19, 2019
  17. Feb 18, 2019
  19. Feb 17, 2019