[openssl] OpenSSL_1_0_2-stable update

[Matt Caswell]

The branch OpenSSL_1_0_2-stable has been updated
       via  b250f2a431ab0cc03a8a1cc4cdc1a7e9ecb052a6 (commit)
      from  9acdddf1acd6f6be41ddb711b6b55fe7f5481320 (commit)


- Log -----------------------------------------------------------------
commit b250f2a431ab0cc03a8a1cc4cdc1a7e9ecb052a6
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 9b95e5f..2a84698 100644
--- a/crypto/bn/bn_lib.c
+++ b/crypto/bn/bn_lib.c
@@ -836,6 +836,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)