Skip to content
GitLab
  1. 28 May, 2019 3 commits
  3. 21 May, 2019 1 commit
  5. 25 Apr, 2019 1 commit
  7. 16 Apr, 2019 1 commit
  9. 30 Mar, 2019 1 commit
  11. 22 Mar, 2019 2 commits
  13. 18 Mar, 2019 1 commit
  15. 17 Mar, 2019 1 commit
  17. 07 Mar, 2019 2 commits
    • Bernd Edlinger's avatar
      Fix memory overrun in rsa padding check functions · 6555a894
      Bernd Edlinger authored 
      Backported from d7f5e5ae



Fixes #8364 and #8357

Reviewed-by: default avatarKurt Roeckx <kurt@roeckx.be>
(Merged from https://github.com/openssl/openssl/pull/8438)
      6555a894
    • Matt Caswell's avatar
      Avoid an underflow in ecp_nistp521.c · d5e37fc8
      Matt Caswell authored 
      

The function felem_diff_128_64 in ecp_nistp521.c substracts the number |in|
from |out| mod p. In order to avoid underflow it first adds 32p mod p
(which is equivalent to 0 mod p) to |out|. The comments and variable naming
suggest that the original author intended to add 64p mod p. In fact it
has been shown that with certain unusual co-ordinates it is possible to
cause an underflow in this function when only adding 32p mod p while
performing a point double operation. By changing this to 64p mod p the
underflow is avoided.

It turns out to be quite difficult to construct points that satisfy the
underflow criteria although this has been done and the underflow
demonstrated. However none of these points are actually on the curve.
Finding points that satisfy the underflow criteria and are also *on* the
curve is considered significantly more difficult. For this reason we do
not believe that this issue is currently practically exploitable and
therefore no CVE has been assigned.

This only impacts builds using the enable-ec_nistp_64_gcc_128 Configure
option.

With thanks to Bo-Yin Yang, Billy Brumley and Dr Liu for their significant
help in investigating this issue.

Reviewed-by: default avatarNicola Tuveri <nic.tuv@gmail.com>
(Merged from https://github.com/openssl/openssl/pull/8405)

(cherry picked from commit 13fbce17)
      d5e37fc8
  19. 26 Feb, 2019 6 commits
  21. 25 Feb, 2019 1 commit
    • Matt Caswell's avatar
      Ensure bn_cmp_words can handle the case where n == 0 · b250f2a4
      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)
      b250f2a4
  23. 20 Feb, 2019 2 commits
    • Nicola Tuveri's avatar
      Clear BN_FLG_CONSTTIME on BN_CTX_get() · 9acdddf1
      Nicola Tuveri authored 
      (cherry picked from commit c8147d37

)

Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8295)
      9acdddf1
    • Nicola Tuveri's avatar
      Test for constant-time flag leakage in BN_CTX · d769ce09
      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.
- 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.

(manually cherry picked from commit fe16ae5f

)

Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/8295)
      d769ce09
  25. 18 Feb, 2019 1 commit
  27. 15 Feb, 2019 1 commit
  29. 15 Jan, 2019 3 commits
  31. 03 Jan, 2019 1 commit
  33. 15 Dec, 2018 1 commit
  35. 12 Dec, 2018 2 commits
  37. 07 Dec, 2018 1 commit
  39. 06 Dec, 2018 5 commits
  41. 03 Dec, 2018 1 commit
  43. 24 Nov, 2018 2 commits