Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(oracle): split version flavors #452

Closed

Conversation

DmitriyLewen
Copy link
Contributor

@DmitriyLewen DmitriyLewen commented Oct 15, 2024

Description

Oracle Linux uses normal, fips (e.g. 3.6.16-4.0.1.el8_fips) and ksplice (e.g. 2:2.28-151.0.1.ksplice2.el8) version flavors.
We need to separate these versions so that we only compare version with same flavors.
See #220 for more details.

PR info

We are currently unable to change the database schema, so this PR is workaround to keep multiple versions for single CVE.
We currently use FixedVersion for OS advisories.
But in this case PatchedVersions was used.

It adds options to save all flavors for single advisory.

To save backward compatibility - we only keep version with normal flavor in FixedVersion.

DB sizes:

before:

-rw-r--r--@ 1 dmitriy  staff    53M Oct  8 16:51 db.tar.gz
-rw-------@ 1 dmitriy  staff   507M Oct  8 16:50 trivy.db

after

-rw-r--r--@ 1 dmitriy  staff    52M Oct 14 17:48 db.tar.gz
-rw-------@ 1 dmitriy  staff   523M Oct 14 17:47 trivy.db

Related PRs

@DmitriyLewen DmitriyLewen self-assigned this Oct 15, 2024
@knqyf263
Copy link
Collaborator

knqyf263 commented Oct 22, 2024

Have you considered using ELSA-IDs for keys? It would require a modification on the Trivy side to also display CVE-IDs, but I don't think it would be that bad since the old Trivy only displays ELSA-IDs instead of CVE-IDs.

@knqyf263
Copy link
Collaborator

I suggested the same before 😄
#221 (comment)

@knqyf263
Copy link
Collaborator

Unless I'm overlooking something, backwards compatibility is diminished - because ELSA ID is used as the key and not the CVE ID, older clients utilizing the database will not be able to resolve the CVE and will report results like the following:

It's a fair point. I totally forgot about it.

@DmitriyLewen
Copy link
Contributor Author

I'm not sure about that.

  1. I can check, but I'm not sure we'll gain in DB size for this solution, because we'll need to create separate Entry for each CVE-ID (or use VendorIDs to merge CVEs with the same versions).
    We can try to use RedHat advisory with fixedVersion as array.
    If it is okay for you - i can try this and detect DB size
  2. We'll need to add logic to remove 2 (or more) fixed versions (e.g. https://linux.oracle.com/cve/CVE-2014-7169.html contains 2 ELSA for bash (OL 5) => 2 fixed versions).
    So Trivy should solve this problem (which means Trivy will waste resources for such cases).

@knqyf263
Copy link
Collaborator

We can try to use RedHat advisory with fixedVersion as array.

Please let me think about it.

I'm now confused about FIPS. This adviosry seems relevant to FIPS according to the description, but the version doesn't contain _fips.

gnutls
[3.7.6-12]
- fips: mark PBKDF2 with short key and output sizes non-approved
- fips: only mark HMAC as approved in PBKDF2
- fips: mark gnutls_key_generate with short key sizes non-approved
- fips: fix checking on hash algorithm used in ECDSA
- fips: preserve operation context around FIPS selftests API

Do you have any ideas?

@DmitriyLewen
Copy link
Contributor Author

hm... i couldn't to think explanation for that...
This is a changelog, so there may be typos...

ELSA-2022-9221 has fips version, but doesn't have fips prefies:

[3.6.16-4.0.1_fips]
- Allow RSA keygen with modulus sizes bigger than 3072 bits and validate the seed length
as defined in FIPS 186-4 section B.3.2 [Orabug: 33200526]
- Allow bigger known RSA modulus sizes when calling
rsa_generate_fips186_4_keypair directly [Orabug: 33200526]
- Change Epoch from 1 to 10

@knqyf263
Copy link
Collaborator

Another question. This vulnerability has no ELSA for FIPS. Does it mean FIPS gnutls is not affected?
It looks like the FIPS gnutls shares the code with the normal gnutls.
https://linux.oracle.com/errata/ELSA-2022-9221.html

@knqyf263
Copy link
Collaborator

This advisory is mixing up normal and fips flavors.

@DmitriyLewen
Copy link
Contributor Author

This vulnerability has no ELSA for FIPS. Does it mean FIPS gnutls is not affected?
It looks like the FIPS gnutls shares the code with the normal gnutls.

Take a look - aquasecurity/trivy#1967 (comment)

Does it mean FIPS gnutls is not affected?

IIUC you are right (or there is no fix for FIPS gnutls)

@@ -39,24 +39,36 @@ func TestVulnSrc_Update(t *testing.T) {
Key: []string{"advisory-detail", "CVE-2007-0493", "Oracle Linux 5", "bind-devel"},
Value: types.Advisory{
FixedVersion: "30:9.3.3-8.el5",
PatchedVersions: []string{
"30:9.3.3-8.el5",
Copy link
Collaborator

@knqyf263 knqyf263 Oct 22, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can use FixedVersion for normal flavor. Do we also need to store this version in PatchedVersions? It helps reduce the size.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hm... after adding arches (#453) this logic will be confusing (because we will only keep normal version for x86_64 arch in FixedVersion)
But i will check your solution to understand how much space we can save.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, I'm wondering how much using PatchedVersions helps from the size perspective after migrating to Advisories in #453.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll write an example. Just a moment.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But I used PatchedVersions in #453 to avoid creating a new Entry for each flavor.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The PatchedVersions method needs a more complicated implementation as it needs to aggregate entries, but the data size will be bigger. There is no reason to go with that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great research! So, we would go for FixedVersion, right?

Right!

The PatchedVersions method needs a more complicated implementation as it needs to aggregate entries, but the data size will be bigger. There is no reason to go with that.

agree with you!

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, so are you going to update this PR?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we don't need to add flavors and arches in one PR.
So I will update this PR, after merging this PR we will add arches.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree. We should add changes step by step.

@DmitriyLewen
Copy link
Contributor Author

close this PR in favor #221

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants