Clair v4 doesn't catch CVE-2022-0778
EvgenyB1001 opened this issue · comments
Description of Problem / Feature Request
We are using both Clair v4.3.6 (clairctl util is used for the scanning) and Clair v2.0.6 (arminc/clair-scanner with the related arminc database are used for the scanning)
While scanning our image it appeared that Clair v4 didn't detect CVE-2022-0778 vulnerability in openssl and openssl11 packages, while Clair v2 with arminc prefilled database actually did it.
Is this a known issue?
Expected Outcome
I would have expected Clair v4 to detect the CVE-2022-0778 vulnerability like it works for Clair v2.
Actual Outcome
Clair v2 output:
[11:02:33][Step 12/12] | STATUS | CVE SEVERITY | PACKAGE NAME | PACKAGE VERSION | CVE DESCRIPTION |
[11:02:33][Step 12/12] +------------+----------------------+----------------+------------------------+-----------------------------------------------------+
[11:02:33][Step 12/12] | Unapproved | High ALAS2-2022-1766 | openssl11-libs | 1:1.1.1g-12.amzn2.0.5 | Package updates are available for Amazon Linux |
[11:02:33][Step 12/12] | | | | | 2 that fix the following vulnerabilities: |
[11:02:33][Step 12/12] | | | | | CVE-2022-0778: The BN_mod_sqrt() function, which |
[11:02:33][Step 12/12] | | | | | computes a modular square root, contains a bug that |
[11:02:33][Step 12/12] | | | | | can cause it to loop forever for non-prime moduli. |
[11:02:33][Step 12/12] | | | | | Internally this function is used when parsing |
[11:02:33][Step 12/12] | | | | | certificates that contain elliptic curve public |
[11:02:33][Step 12/12] | | | | | keys in compressed form or explicit elliptic curve |
[11:02:33][Step 12/12] | | | | | parameters with a base point encoded in compressed |
[11:02:33][Step 12/12] | | | | | form. It is possible to trigger the infinite loop |
[11:02:33][Step 12/12] | | | | | by crafting a certificate that has invalid explicit |
[11:02:33][Step 12/12] | | | | | curve parameters. Since certificate parsing happens |
[11:02:33][Step 12/12] | | | | | prior to verification of the certificate signature, |
[11:02:33][Step 12/12] | | | | | any process that parses an externally supplied |
[11:02:33][Step 12/12] | | | | | certificate may thus be subject to a denial of |
[11:02:33][Step 12/12] | | | | | service attack. The infinite loop can also be |
[11:02:33][Step 12/12] | | | | | reached when parsing crafted private keys as they |
[11:02:33][Step 12/12] | | | | | can contain explicit elliptic curve parameters. |
[11:02:33][Step 12/12] | | | | | Thus vulnerable situations include: - TLS clients |
[11:02:33][Step 12/12] | | | | | consuming server certificates - TLS servers |
[11:02:33][Step 12/12] | | | | | consuming client certificates - Hosting providers |
[11:02:33][Step 12/12] | | | | | taking certificates or private keys from customers |
[11:02:33][Step 12/12] | | | | | - Certificate authorities parsing certification |
[11:02:33][Step 12/12] | | | | | requests from subscribers - Anything else which |
[11:02:33][Step 12/12] | | | | | parses ASN.1 elliptic curve parameters Also any |
[11:02:33][Step 12/12] | | | | | other applications that use the BN_mod_sqrt() |
[11:02:33][Step 12/12] | | | | | where the attacker can control the parameter |
[11:02:33][Step 12/12] | | | | | values are vulnerable to this DoS issue. In the |
[11:02:33][Step 12/12] | | | | | OpenSSL 1.0.2 version the public key is not parsed |
[11:02:33][Step 12/12] | | | | | during initial parsing of the certificate which |
[11:02:33][Step 12/12] | | | | | makes it slightly harder to trigger the infinite |
[11:02:33][Step 12/12] | | | | | loop. However any operation which requires the |
[11:02:33][Step 12/12] | | | | | public key from the certificate will trigger the |
[11:02:33][Step 12/12] | | | | | infinite loop. In particular the attacker can |
[11:02:33][Step 12/12] | | | | | use a self-signed certificate to trigger the loop |
[11:02:33][Step 12/12] | | | | | during verification of the certificate signature. |
[11:02:33][Step 12/12] | | | | | This issue affects OpenSSL versions 1.0.2, 1.1.1 |
[11:02:33][Step 12/12] | | | | | and 3.0. It was addressed in the releases of |
[11:02:33][Step 12/12] | | | | | 1.1.1n and 3.0.2 on the 15th March 2022. Fixed |
[11:02:33][Step 12/12] | | | | | in OpenSSL 3.0.2 (Affected 3.0.0,3.0.1). Fixed |
[11:02:33][Step 12/12] | | | | | in OpenSSL 1.1.1n (Affected 1.1.1-1.1.1m). Fixed |
[11:02:33][Step 12/12] | | | | | in OpenSSL 1.0.2zd (Affected 1.0.2-1.0.2zc). |
[11:02:33][Step 12/12] | | | | | https://alas.aws.amazon.com/AL2/ALAS-2022-1766.html |
[11:02:33][Step 12/12] +------------+----------------------+----------------+------------------------+-----------------------------------------------------+
[11:02:33][Step 12/12] | Unapproved | High ALAS2-2022-1766 | openssl-libs | 1:1.0.2k-19.amzn2.0.10 | Package updates are available for Amazon Linux |
[11:02:33][Step 12/12] | | | | | 2 that fix the following vulnerabilities: |
[11:02:33][Step 12/12] | | | | | CVE-2022-0778: The BN_mod_sqrt() function, which |
[11:02:33][Step 12/12] | | | | | computes a modular square root, contains a bug that |
[11:02:33][Step 12/12] | | | | | can cause it to loop forever for non-prime moduli. |
[11:02:33][Step 12/12] | | | | | Internally this function is used when parsing |
[11:02:33][Step 12/12] | | | | | certificates that contain elliptic curve public |
[11:02:33][Step 12/12] | | | | | keys in compressed form or explicit elliptic curve |
[11:02:33][Step 12/12] | | | | | parameters with a base point encoded in compressed |
[11:02:33][Step 12/12] | | | | | form. It is possible to trigger the infinite loop |
[11:02:33][Step 12/12] | | | | | by crafting a certificate that has invalid explicit |
[11:02:33][Step 12/12] | | | | | curve parameters. Since certificate parsing happens |
[11:02:33][Step 12/12] | | | | | prior to verification of the certificate signature, |
[11:02:33][Step 12/12] | | | | | any process that parses an externally supplied |
[11:02:33][Step 12/12] | | | | | certificate may thus be subject to a denial of |
[11:02:33][Step 12/12] | | | | | service attack. The infinite loop can also be |
[11:02:33][Step 12/12] | | | | | reached when parsing crafted private keys as they |
[11:02:33][Step 12/12] | | | | | can contain explicit elliptic curve parameters. |
[11:02:33][Step 12/12] | | | | | Thus vulnerable situations include: - TLS clients |
[11:02:33][Step 12/12] | | | | | consuming server certificates - TLS servers |
[11:02:33][Step 12/12] | | | | | consuming client certificates - Hosting providers |
[11:02:33][Step 12/12] | | | | | taking certificates or private keys from customers |
[11:02:33][Step 12/12] | | | | | - Certificate authorities parsing certification |
[11:02:33][Step 12/12] | | | | | requests from subscribers - Anything else which |
[11:02:33][Step 12/12] | | | | | parses ASN.1 elliptic curve parameters Also any |
[11:02:33][Step 12/12] | | | | | other applications that use the BN_mod_sqrt() |
[11:02:33][Step 12/12] | | | | | where the attacker can control the parameter |
[11:02:33][Step 12/12] | | | | | values are vulnerable to this DoS issue. In the |
[11:02:33][Step 12/12] | | | | | OpenSSL 1.0.2 version the public key is not parsed |
[11:02:33][Step 12/12] | | | | | during initial parsing of the certificate which |
[11:02:33][Step 12/12] | | | | | makes it slightly harder to trigger the infinite |
[11:02:33][Step 12/12] | | | | | loop. However any operation which requires the |
[11:02:33][Step 12/12] | | | | | public key from the certificate will trigger the |
[11:02:33][Step 12/12] | | | | | infinite loop. In particular the attacker can |
[11:02:33][Step 12/12] | | | | | use a self-signed certificate to trigger the loop |
[11:02:33][Step 12/12] | | | | | during verification of the certificate signature. |
[11:02:33][Step 12/12] | | | | | This issue affects OpenSSL versions 1.0.2, 1.1.1 |
[11:02:33][Step 12/12] | | | | | and 3.0. It was addressed in the releases of |
[11:02:33][Step 12/12] | | | | | 1.1.1n and 3.0.2 on the 15th March 2022. Fixed |
[11:02:33][Step 12/12] | | | | | in OpenSSL 3.0.2 (Affected 3.0.0,3.0.1). Fixed |
[11:02:33][Step 12/12] | | | | | in OpenSSL 1.1.1n (Affected 1.1.1-1.1.1m). Fixed |
[11:02:33][Step 12/12] | | | | | in OpenSSL 1.0.2zd (Affected 1.0.2-1.0.2zc). |
[11:02:33][Step 12/12] | | | | | https://alas.aws.amazon.com/AL2/ALAS-2022-1766.html |
[11:02:33][Step 12/12] +------------+----------------------+----------------+------------------------+-----------------------------------------------------+
Environment
- Clair version/image: v4.3.6
- Clair client name/version: clairtctl v4.3.6
- Host OS: Ubuntu 20.04.4 LTS
- Kernel (e.g.
uname -a): Linux ip-aws #19~20.04.1-Ubuntu SMP Mon Mar 7 12:53:12 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux - Kubernetes version (use
kubectl version): - Network/Firewall setup: Containers using host network
What steps did you take? Please attach clair logs and config, and clairctl report's json output.
Currently, could not be reproduced because of the base image has been updated and the specified vulenrability is not presented anymore. The issue coul be closed