[openssl] OpenSSL_1_1_0-stable update

[Matt Caswell]

The branch OpenSSL_1_1_0-stable has been updated
       via  ad01b01c16b0b9d95de79c3b01398e3582a5105b (commit)
      from  3318493b85a8189f6385d5489f97f0e101471f92 (commit)


- Log -----------------------------------------------------------------
commit ad01b01c16b0b9d95de79c3b01398e3582a5105b
Author: Matt Caswell <matt at openssl.org>
Date:   Mon Feb 25 11:28:32 2019 +0000

    Ensure bn_cmp_words can handle the case where n == 0
    
    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: Paul Dale <paul.dale at oracle.com>
    Reviewed-by: Viktor Dukhovni <viktor at openssl.org>
    (Merged from https://github.com/openssl/openssl/pull/8326)
    
    (cherry picked from commit 576129cd72ae054d246221f111aabf42b9c6d76d)

-----------------------------------------------------------------------

Summary of changes:
 crypto/bn/bn_lib.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/crypto/bn/bn_lib.c b/crypto/bn/bn_lib.c
index 3f3c7bb..9885b0c 100644
--- a/crypto/bn/bn_lib.c
+++ b/crypto/bn/bn_lib.c
@@ -780,6 +780,9 @@ int bn_cmp_words(const BN_ULONG *a, const BN_ULONG *b, int n)
     int i;
     BN_ULONG aa, bb;
 
+    if (n == 0)
+        return 0;
+
     aa = a[n - 1];
     bb = b[n - 1];
     if (aa != bb)