Metadata? Earlier revs of a file?

[elear]

What to do when you've made a change to a file and hash is changed, but there is a vulnerability associated with the old hash? Should the old hash be in the gitbom?

[elear]

This is a primary use case for me. The idea is this:

filea.c had a git hash of X1 when it was pulled from a repo, and is part of Package P. Due to whatever integration, it now has hash X2. Now a vulnerability is announced on Package P with filea with hash X1. Question: how should one spot the problem, and how does one know the state of that file?

Several thoughts:

• If one has the source, and if as a matter of course one maintains a list of githashes of all files ever touched, then one can simply do a dip and return the relevant file, and see how it fast forwarded.
• But if one simply has a githash and a gitbom as we envision because one is, say, a customer of an IoT component, then the hash is, at least, by default not present.

In that latter case, the maintainer could conceivably provide the hash db from use case 1, but that could get quite large and you cannot see whether the correction was applied.

To fix that latter problem, as a matter of operational practice, if the githash of both the vulnerable and corrected code is provided in an advisory, then the maintainer can rewind, apply the change, and then re-apply any integration work.

This leads to how to indicate that the fixed code is present, without having to provide the lengthy history. THAT hash is absolutely meta-data but critical meta-data. So let’s not lose it.

[yonhan3]

Hi Eliot,

Thanks for creating this issue.

This issue looks like an issue that has been solved by Bomsh for CVE search using gitBOM. well, perhaps not perfectly solved, but partially solved. I would like to share with you of Bomsh's implementation for this issue.

For CVE searching, we have noticed that some Linux distros like Fedora/Centos apply its own patches (including backporting of CVE fixes) on top of the official OpenSSL source tarballs, which creates new blob IDs that do not exist in the official OpenSSL git repo. The bomsh_create_cve.py script scans the whole OpenSSL git repo and creates the CVE database for all CVE-relevant blob IDs, which do not include the newly created blob IDs by Fedora/Centos. As a result, when running bomsh_search_cve.py script, it reports a warning as below:

$ bomsh_search_cve.py -d /home/openssl_bomsh_created_cvedb2.json -r .gitbom2/metadata/bomsh/bomsh_gitbom_treedb -vv -f /var/lib/mock/almalinux-8-x86_64/result/openssl-libs-1.1.1k-5.el8.x86_64.rpm

All not-found new CVE blobs: {
    "4c376c5b31f5c4ec4c7afb3bbef06fa5ceba4a92": [
        "crypto/x509/x509_vfy.c",
        "/builddir/build/BUILD/openssl-1.1.1k/crypto/x509/x509_vfy.c"
    ],
    "6aff0d31e2978b449988cfac308571f89ae49bf2": [
        "ssl/t1_lib.c",
        "/builddir/build/BUILD/openssl-1.1.1k/ssl/t1_lib.c"
    ],
    "dfaf77f3dd7667386f4340c3272f669395707689": [
        "ssl/statem/extensions.c",
        "/builddir/build/BUILD/openssl-1.1.1k/ssl/statem/extensions.c"
    ]
}
Warning: the CVE search result may be inaccurate, since 3 blob IDs are not found in CVE DB

Here is the CVE search results:
{
    "/var/lib/mock/almalinux-8-x86_64/result/openssl-libs-1.1.1k-5.el8.x86_64.rpm": {
        "CVElist": [
            "CVE-2022-0778"
        ],
        "FixedCVElist": [
            "CVE-2020-1971",
            "CVE-2014-0160"
        ],
        "NoCVElist": [],
        "cvehint_CVElist": [],
        "cvehint_FixedCVElist": []
    }
}

The bomsh_create_cve.py script has been enhanced to scan the git repo of the Fedora/Centos, and find all the newly created blob IDs for all the git commits. With the help of CVE checking rules, this script generates the database for these new blob IDs like below:

    "11e5659caaab0f2d09f895cffd01e21f484111ec": {
        "baseline_blob_id": "7f40bfabe0507a484db1031bcedbec047f453030",
        "cvehint_CVElist": [],
        "cvehint_FixedCVElist": [
            "CVE-2020-1971"
        ],
        "cvehints": {
            "CVE-2020-1971": {
                "cveadd": false,
                "cvefix": true
            }
        },
        "file_path": "crypto/x509v3/v3_genn.c"
    },

It evaluates each source file directly with the CVE checking rules and also it tells you the baseline githash (the "baseline_blob_id" field). This way, Bomsh can create a CVE database that covers the new blob IDs that are created by Fedora/centos distros too.

There is another scenario that Bomsh supports: when generating gitBOM tree with Bomsh, bomsh_hook2.py script can directly check the source files against the CVE checking rules, and generate some metadata regarding the CVE check results. These additional metadata is put into .gitbom/metadata/bomsh/ directory, and later when searching CVE, the bomsh_search_cve.py script utilizes these CVE metadata, and can report CVE vulnerability for binaries. This cover all newly found blob IDs that do not exist in the CVE database.

But anyway, bomsh_search_cve.py script reports a warning when such non-existent blob IDs are found during CVE search, which prompts users to manually inspect those source files.

For the implementation details, please check the Bomsh git repo and the openssl-cve repo:

Bomsh: https://github.com/git-bom/bomsh
openssl-cve: https://github.com/yonhan3/openssl-cve