Merge pull request !130 from code4lala/fix-CVE-2023-3817-for-OpenHarmony-3.2-Release

Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21551)
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>

If  |q| >= |p| then the q value is obviously wrong as q
is supposed to be a prime divisor of p-1.

We check if p is overly large so this added test implies that
q is not large either when performing subsequent tests using that
q value.

Otherwise if it is too large these additional checks of the q value
such as the primality test can then trigger DoS by doing overly long
computations.

Fixes CVE-2023-3817
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21551)
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>

Merge pull request !126 from code4lala/fix-CVE-2023-3446-for-OpenHarmony-3.2-Release

Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NTom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21452)
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>

Confirm that the only errors DH_check() finds with DH parameters with an
excessively long modulus is that the modulus is too large. We should not
be performing time consuming checks using that modulus.
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NTom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21452)
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>

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: NPaul Dale <pauli@openssl.org>
Reviewed-by: NTom Cosgrove <tom.cosgrove@arm.com>
Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/21452)
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>

Merge pull request !117 from code4lala/OpenHarmony-3.2-Release

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: NMatt Caswell <matt@openssl.org>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>

Merge pull request !101 from code4lala/OpenHarmony-3.2-Release

The function was incorrectly documented as enabling policy checking.

Fixes: CVE-2023-0466
Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NPaul Dale <pauli@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20564)
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>

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: NHugo Landau <hlandau@openssl.org>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/20588)
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>

A security vulnerability has been identified in all supported versions
of OpenSSL related to the verification of X.509 certificate chains
that include policy constraints.  Attackers may be able to exploit this
vulnerability by creating a malicious certificate chain that triggers
exponential use of computational resources, leading to a denial-of-service
(DoS) attack on affected systems.

Fixes CVE-2023-0464
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Reviewed-by: NShane Lontis <shane.lontis@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/20569)
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>

Merge pull request !79 from code4lala/monthly_20221018

add rsa_sup_mul.c from CVE-2022-4304 fix https://github.com/openssl/openssl/commit/43d8f88511991533f53680a751e9326999a6a31fSigned-off-by: Ncode4lala <fengziteng2@huawei.com>

A timing based side channel exists in the OpenSSL RSA Decryption
implementation which could be sufficient to recover a plaintext across
a network in a Bleichenbacher style attack. To achieve a successful
decryption an attacker would have to be able to send a very large number
of trial messages for decryption. The vulnerability affects all RSA
padding modes: PKCS#1 v1.5, RSA-OEAP and RSASVE.

Patch written by Dmitry Belyavsky and Hubert Kario

CVE-2022-4304
Reviewed-by: NDmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>

Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>

If the aux->asn1_cb() call fails in BIO_new_NDEF then the "out" BIO will
be part of an invalid BIO chain. This causes a "use after free" when the
BIO is eventually freed.

Based on an original patch by Viktor Dukhovni and an idea from Theo
Buehler.

Thanks to Octavio Galland for reporting this issue.
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NTomas Mraz <tomas@openssl.org>
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>

Call PEM_read_bio_ex() and expect a failure. There should be no dangling
ptrs and therefore there should be no double free if we free the ptrs on
error.
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NHugo Landau <hlandau@openssl.org>
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>

In the event of a failure in PEM_read_bio_ex() we free the buffers we
allocated for the header and data buffers. However we were not clearing
the ptrs stored in *header and *data. Since, on success, the caller is
responsible for freeing these ptrs this can potentially lead to a double
free if the caller frees them even on failure.

Thanks to Dawei Wang for reporting this issue.

Based on a proposed patch by Kurt Roeckx.

CVE-2022-4450
Reviewed-by: NPaul Dale <pauli@openssl.org>
Reviewed-by: NHugo Landau <hlandau@openssl.org>
Signed-off-by: Ncode4lala <fengziteng2@huawei.com>

Merge pull request !72 from code4lala/monthly_20221018

Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
Change-Id: Ie2857a7388c4b7e17d84dd48ec150530983db773

Merge pull request !74 from 周海锋/monthly_20221018

Signed-off-by: Nzhouhaifeng <kutcher.zhou@huawei.com>

Signed-off-by: Ncode4lala <fengziteng2@huawei.com>
Change-Id: Icb4f5b98f8466ed760026495de9e097b3fa46d04

Merge pull request !69 from ltdong/master

Signed-off-by: Nltdong <donglongtao@huawei.com>

Merge pull request !70 from zhangcui/master

Signed-off-by: Nzhang-cui11 <zhangcui11@huawei.com>

Signed-off-by: Nltdong <donglongtao@huawei.com>

Merge pull request !68 from zhao_zhen_zhou/master

Signed-off-by: Nzhao_zhen_zhou <zhaozhenzhou@huawei.com>

Merge pull request !62 from zhao_zhen_zhou/master

Signed-off-by: Nzhao_zhen_zhou <zhaozhenzhou@huawei.com>

Merge pull request !61 from zhao_zhen_zhou/master

Signed-off-by: Nzhao_zhen_zhou <zhaozhenzhou@huawei.com>

Merge pull request !50 from zhao_zhen_zhou/master

Signed-off-by: Nzhao_zhen_zhou <zhaozhenzhou@huawei.com>

Merge pull request !60 from zhao_zhen_zhou/master