fix CVE-2023-3446 CVE-2023-0465 CVE-2023-2650

backport-CVE-2023-0465.patch

@@ -0,0 +1,56 @@
+From b013765abfa80036dc779dd0e50602c57bb3bf95 Mon Sep 17 00:00:00 2001
+From: Matt Caswell <matt@openssl.org>
+Date: Tue, 7 Mar 2023 16:52:55 +0000
+Subject: [PATCH] Ensure that EXFLAG_INVALID_POLICY is checked even in
+leaf
+ certs
+
+Even though we check the leaf cert to confirm it is valid, we
+later ignored the invalid flag and did not notice that the leaf
+cert was bad.
+
+Fixes: CVE-2023-0465
+
+Reviewed-by: Hugo Landau <hlandau@openssl.org>
+Reviewed-by: Tomas Mraz <tomas@openssl.org>
+(Merged from https://github.com/openssl/openssl/pull/20588)
+
+Reference:https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=b013765abfa80036dc779dd0e50602c57bb3bf95
+Conflict: Context conflict
+---
+ Cryptlib/OpenSSL/crypto/x509/x509_vfy.c | 11 +++++++++--
+ 1 file changed, 9 insertions(+), 2 deletions(-)
+
+diff --git a/Cryptlib/OpenSSL/crypto/x509/x509_vfy.c b/Cryptlib/OpenSSL/crypto/x509/x509_vfy.c
+index 96f306b..a6878fe 100644
+--- a/Cryptlib/OpenSSL/crypto/x509/x509_vfy.c
++++ b/Cryptlib/OpenSSL/crypto/x509/x509_vfy.c
+@@ -1768,16 +1768,23 @@ static int check_policy(X509_STORE_CTX *ctx)
+          * Locate certificates with bad extensions and notify callback.
+          */
+         X509 *x;
+-        int i;
+-        for (i = 1; i < sk_X509_num(ctx->chain); i++) {
++        int i, cbcalled = 0;
++        for (i = 0; i < sk_X509_num(ctx->chain); i++) {
+             x = sk_X509_value(ctx->chain, i);
+             if (!(x->ex_flags & EXFLAG_INVALID_POLICY))
+                 continue;
++	    cbcalled = 1;
+             ctx->current_cert = x;
+             ctx->error = X509_V_ERR_INVALID_POLICY_EXTENSION;
+             if (!ctx->verify_cb(0, ctx))
+                 return 0;
+         }
++        if (!cbcalled) {
++            /* Should not be able to get here */
++            X509err(X509_F_CHECK_POLICY, ERR_R_INTERNAL_ERROR);
++            return 0;
++        }
++        /* The callback ignored the error so we return success */
+         return 1;
+     }
+     if (ret == -2) {
+-- 
+2.33.0
+

backport-CVE-2023-2650.patch

@@ -0,0 +1,67 @@
+From 423a2bc737a908ad0c77bda470b2b59dc879936b Mon Sep 17 00:00:00 2001
+From: Richard Levitte <levitte@openssl.org>
+Date: Fri, 12 May 2023 10:00:13 +0200
+Subject: [PATCH] Restrict the size of OBJECT IDENTIFIERs that OBJ_obj2txt will
+ translate
+
+Reference:https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=423a2bc737a908ad0c77bda470b2b59dc879936b
+Conflict:NA
+
+OBJ_obj2txt() would translate any size OBJECT IDENTIFIER to canonical
+numeric text form.  For gigantic sub-identifiers, this would take a very
+long time, the time complexity being O(n^2) where n is the size of that
+sub-identifier.
+
+To mitigate this, a restriction on the size that OBJ_obj2txt() will
+translate to canonical numeric text form is added, based on RFC 2578
+(STD 58), which says this:
+
+> 3.5. OBJECT IDENTIFIER values
+>
+> An OBJECT IDENTIFIER value is an ordered list of non-negative numbers.
+> For the SMIv2, each number in the list is referred to as a sub-identifier,
+> there are at most 128 sub-identifiers in a value, and each sub-identifier
+> has a maximum value of 2^32-1 (4294967295 decimal).
+
+Fixes otc/security#96
+Fixes CVE-2023-2650
+
+Reviewed-by: Matt Caswell <matt@openssl.org>
+Reviewed-by: Tomas Mraz <tomas@openssl.org>
+---
+ crypto/objects/obj_dat.c | 19 +++++++++++++++++++
+ 1 files changed, 50 insertions(+)
+
+diff --git a/crypto/objects/obj_dat.c b/crypto/objects/obj_dat.c
+index 01cde00e98..c0e55197a0 100644
+--- a/Cryptlib/OpenSSL/crypto/objects/obj_dat.c
++++ b/Cryptlib/OpenSSL/crypto/objects/obj_dat.c
+@@ -443,6 +443,25 @@ int OBJ_obj2txt(char *buf, int buf_len, const ASN1_OBJECT *a, int no_name)
+     first = 1;
+     bl = NULL;
+ 
++    /*
++     * RFC 2578 (STD 58) says this about OBJECT IDENTIFIERs:
++     *
++     * > 3.5. OBJECT IDENTIFIER values
++     * >
++     * > An OBJECT IDENTIFIER value is an ordered list of non-negative
++     * > numbers. For the SMIv2, each number in the list is referred to as a
++     * > sub-identifier, there are at most 128 sub-identifiers in a value,
++     * > and each sub-identifier has a maximum value of 2^32-1 (4294967295
++     * > decimal).
++     *
++     * So a legitimate OID according to this RFC is at most (32 * 128 / 7),
++     * i.e. 586 bytes long.
++     *
++     * Ref: https://datatracker.ietf.org/doc/html/rfc2578#section-3.5
++     */
++    if (len > 586)
++        goto err;
++
+     while (len > 0) {
+         l = 0;
+         use_bn = 0;
+-- 
+2.34.1
+

backport-CVE-2023-3446.patch

@@ -0,0 +1,77 @@
+From 8780a896543a654e757db1b9396383f9d8095528 Mon Sep 17 00:00:00 2001
+From: Matt Caswell <matt@openssl.org>
+Date: Thu, 6 Jul 2023 16:36:35 +0100
+Subject: [PATCH] Fix DH_check() excessive time with over sized modulus
+
+The DH_check() function checks numerous aspects of the key or parameters
+that have been supplied. Some of those checks use the supplied modulus
+value even if it is excessively large.
+
+There is already a maximum DH modulus size (10,000 bits) over which
+OpenSSL will not generate or derive keys. DH_check() will however still
+perform various tests for validity on such a large modulus. We introduce
+a
+new maximum (32,768) over which DH_check() will just fail.
+
+An application that calls DH_check() and supplies a key or parameters
+obtained from an untrusted source could be vulnerable to a Denial of
+Service attack.
+
+The function DH_check() is itself called by a number of other OpenSSL
+functions. An application calling any of those other functions may
+similarly be affected. The other functions affected by this are
+DH_check_ex() and EVP_PKEY_param_check().
+
+CVE-2023-3446
+
+Reviewed-by: Paul Dale <pauli@openssl.org>
+Reviewed-by: Tom Cosgrove <tom.cosgrove@arm.com>
+Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
+Reviewed-by: Tomas Mraz <tomas@openssl.org>
+(Merged from https://github.com/openssl/openssl/pull/21452)
+---
+ Cryptlib/Include/openssl/dh.h         | 5 +++++
+ Cryptlib/OpenSSL/crypto/dh/dh_check.c | 4 ++++
+ 2 files changed, 9 insertions(+)
+
+diff --git a/Cryptlib/Include/openssl/dh.h b/Cryptlib/Include/openssl/dh.h
+index 6488879..06142df 100644
+--- a/Cryptlib/Include/openssl/dh.h
++++ b/Cryptlib/Include/openssl/dh.h
+@@ -77,6 +77,10 @@
+ #  define OPENSSL_DH_MAX_MODULUS_BITS    10000
+ # endif
+ 
++# ifndef OPENSSL_DH_CHECK_MAX_MODULUS_BITS
++#  define OPENSSL_DH_CHECK_MAX_MODULUS_BITS 32768
++# endif
++
+ # define DH_FLAG_CACHE_MONT_P     0x01
+ 
+ /*
+@@ -356,6 +360,7 @@ void ERR_load_DH_strings(void);
+ # define DH_F_COMPUTE_KEY                                 102
+ # define DH_F_DHPARAMS_PRINT_FP                           101
+ # define DH_F_DH_BUILTIN_GENPARAMS                        106
++# define DH_F_DH_CHECK                                    126
+ # define DH_F_DH_CMS_DECRYPT                              117
+ # define DH_F_DH_CMS_SET_PEERKEY                          118
+ # define DH_F_DH_CMS_SET_SHARED_INFO                      119
+diff --git a/Cryptlib/OpenSSL/crypto/dh/dh_check.c b/Cryptlib/OpenSSL/crypto/dh/dh_check.c
+index 9f3b174..9c62da4 100644
+--- a/Cryptlib/OpenSSL/crypto/dh/dh_check.c
++++ b/Cryptlib/OpenSSL/crypto/dh/dh_check.c
+@@ -78,6 +78,10 @@ int DH_check(const DH *dh, int *ret)
+     BN_ULONG l;
+     BIGNUM *t1 = NULL, *t2 = NULL;
+ 
++    /* Don't do any check at all with an excessively large modulus */
++    if (BN_num_bits(dh->p) > OPENSSL_DH_CHECK_MAX_MODULUS_BITS) {
++        return 0;
++    }
+     *ret = 0;
+     ctx = BN_CTX_new();
+     if (ctx == NULL)
+-- 
+2.27.0
+

shim.spec

@@ -22,7 +22,7 @@
 
 Name:		shim
 Version:	15
-Release:        34
+Release:        35
 Summary:	First-stage UEFI bootloader
 ExclusiveArch:  x86_64 aarch64
 License:	BSD
@@ -58,6 +58,9 @@ Patch23:        backport-CVE-2023-0464.patch
 Patch24:        backport-CVE-2023-3817.patch
 Patch25:        backport-CVE-2023-40551-pe-relocate-Fix-bounds-check-for-MZ-b.patch
 Patch26:        backport-CVE-2023-40547-avoid-incorrectly-trusting-HTTP-heade.patch
+Patch27:        backport-CVE-2023-3446.patch
+Patch28:        backport-CVE-2023-0465.patch
+Patch29:        backport-CVE-2023-2650.patch
 
 # Feature
 Patch9000:	Feature-add-tpcm-support-with-ipmi-channel.patch
@@ -162,6 +165,9 @@ cd ..
 /usr/src/debug/%{name}-%{version}-%{release}/*
 
 %changelog
+* Wed Feb 28 2024 zhengxiaoxiao <zhengxiaoxiao2@huawei.com> - 15-35
+- fix CVE-2023-3446 CVE-2023-0465 CVE-2023-2650
+
 * Tue Jan 30 2024 jinlun <jinlun@huawei.com> - 15-34
 - fix CVE-2023-40547 CVE-2023-40551