micrium uC/Lib vulnerability causes cve-bin-tool to delete triage response data from triage input file

[tzirn]

Description

cve-bin-tool deletes triage analysis/response to micrium uC/Lib vulnerability. We have micrium uC/Lib listed in our CSV SBOM and there is 1 vulnerability for micrium uC/lib. cve-bin-tool finds it and we have it output the vulnerabilities into a vex file. We then add analysis/triage responses within the vex file to all the vulnerabilities found. When I re-run the cve-bin-tool with that vex file as input it uses all the responses correctly in the output report except for the uC/Lib one - it always deletes/ignores the data I've added and lists it as "unexplored" in the remarks field of the output report. The rest are correct.

To reproduce

Steps to reproduce the behavior:

1. have a CSV SBOM with the following columns and data in it for the uC/Lib entity (product string was retrieved directly from the official-cpe-dictionarey_v2.3.xml) An SBOM with just uC/Lib listed is also attached below
   vendor: micrium; product: uc/lib; version 1.38.01; name: micrium uC/OS Lib; Unique Identifier: cpe:2.3:a:micrium:uc/lib:1.38.00:::::::*; type: library; relationship: included in app; URL: https://www.silabls.com/developers/micrium-os;
2. have a triage input file with the data from the example file below in the "feel free to add any other context here" section
3. scan using these flags/this command line: cve-bin-tool -i test_SBOM.csv --triage-input-file test-triageFile.vex -f html,csv --vex test-triage_out.vex -o vulnerability-report-out

Expected behaviour: The output report files should list CVE-2021-26706 as triaged with the data put in the triage input file
Actual behaviour: The output report files list CVE-2021-26706 as unexplored

Version/platform info

Version of CVE-bin-tool( e.g. output of cve-bin-tool --version): 3.3
Installed from pypi or github? pypi
Operating system: Linux/Windows

• On Windows you can run systeminfo | findstr /B /C:"OS Name" /C:"OS Version"
  OS Name: Microsoft Windows 10 Pro
  OS Version: 10.0.19042 N/A Build 19042
  Python version (e.g. python3 --version): python v2.7
  Running in any particular CI environment we should know about? (e.g. Github Actions) None

Anything else?

Feel free to add any other context here.
see attached example SBOM, and output csv file and a screen shot of the vex file input vs vex file output (jpg) (I can't attach the triage vex input or output files or the HTML file - your tool doesnt support those types )
test_SBOM.csv
vulnerability-report-out.csv

**Contents of test-triageFile.vex INPUT file **
{
"bomFormat": "CycloneDX",
"specVersion": "1.4",
"version": 1,
"vulnerabilities": [
{
"id": "CVE-2021-26706",
"source": {
"name": "NVD",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-26706"
},
"ratings": [
{
"source": {
"name": "NVD",
"url": "https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?name=CVE-2021-26706&vector=CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H&version=3.1"
},
"score": 9.8,
"severity": "critical",
"method": "CVSSv3",
"vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"
}
],
"description": "An issue was discovered in lib_mem.c in Micrium uC/OS uC/LIB 1.38.x and 1.39.00. The following memory allocation functions do not check for integer overflow when allocating a pool whose size exceeds the address space: Mem_PoolCreate, Mem_DynPoolCreate, and Mem_DynPoolCreateHW. Because these functions use multiplication to calculate the pool sizes, the operation may cause an integer overflow if the arguments are large enough. The resulting memory pool will be smaller than expected and may be exploited by an attacker.",
"recommendation": "",
"advisories": [],
"created": "NOT_KNOWN",
"published": "NOT_KNOWN",
"updated": "",
"analysis": {
"state": "not_affected",
"response": [
"code_not_reachable"
],
"detail": "NotAffected: affects micrium uC/LIB however those functions NOT USED by Embedded apps",
"justification": "code_not_reachable"
},
"affects": [
{
"ref": "urn:cbt:1/micrium#uc\/lib:1.38.01"
}
]
}
]
}

[terriko]

That definitely sounds like a bug. @mastersans just did a huge rework of the triage system that's poised to come out in 3.4 : do you mind trying the 3.4rc1 build and seeing if you have the same issue or if he's already fixed that issue?

https://pypi.org/project/cve-bin-tool/3.4rc1/

Also, a quick heads up: you're showing as using python2.7 which we stopped supporting when it stopped getting security updates. I doubt this problem is related to that, but I'm honestly a bit surprised that it still works at all in 2.7. I figured by now we'd have used something too new and it would have broken.

[tzirn]

I have Python 3.1.1 also on my computer I can try it with that easily enough first.
Then I'll download the new cve-bin-tool and try v3.4rc1. I'll let you know

[tzirn]

It still happens with python 3.1.1

[tzirn]

I downloaded cve-bin-tool v3.4rc1 and it seems a few of the parameters/options have changed also.
I used to run this command:

cve-bin-tool -i my_SBOM.csv --triage-input-file cve-bin-tool_triageFile.vex -f html,csv --vex triage9c_out.vex
The new version complained about the --vex option for the output file so I changed that to --vex-output
The new version then complained about the --triage-input-file option so tried to change it to --filter-triage
Please let me know if those are the correct command option substitutions.

So then I ran the command like this:

cve-bin-tool -i my_SBOM.csv --filter-triage cve-bin-tool_triageFile.vex -f html,csv --vex-output triage9d_out.vex
and the last 3 lines of output was:
INFO cve_bin_tool - Overall CVE summary: cli.py:1140
INFO cve_bin_tool - There are 0 products with known CVEs detected cli.py:1141
ERROR cve_bin_tool - Please provide --product, --release and --vendor for VEX generation cli.py:1169

With my full SBOM and cve-bin-tool v3.3 there are 4 products with known CVEs and the last lines of output are:

cve-bin-tool -i my_SBOM.csv --triage-input-file cve-bin-tool_triageFile.vex -f html,csv --vex triage9c_out.vex
INFO cve_bin_tool - There are 4 products with known CVEs detected cli.py:1060
INFO cve_bin_tool - Known CVEs in ('micrium.uc\/lib', '1.38.01'), ('micro-ecc_project.micro-ecc', '1.0'), ('qt.qt', '5.12.11'), cli.py:1071
('silabs.micrium_os', '3.04.05'):
INFO cve_bin_tool.OutputEngine - CSV report stored at init.py:1029
C:\Workspace\Mainline\Documentation\Software\SBOM\output.cve-bin-tool.2024-09-04.10-50-49.csv
[10:50:50] INFO cve_bin_tool.OutputEngine - HTML report stored at init.py:1029
C:\Workspace\Mainline\Documentation\Software\SBOM\output.cve-bin-tool.2024-09-04.10-50-49.html

Please advise as to what else has changed with this version so I can get it to run correctly.
Thanks!

[terriko]

@mastersans has the new docs here: https://cve-bin-tool.readthedocs.io/en/latest/triaging_process.html

[mastersans]

@tzirn the .vex file extension has been deprecated and we now support Json for cyclonedx, openvex and csaf, you can checkout new vex process in the docs @terriko shared.

Thanks

[tzirn]

If you are changing options and taking away support for vex files it sounds like this is a major overhaul and maybe shouldnt just be numbered 3.4 but instead 4.0.
I dont have time right now to learn how to change my VEX files into the JSON this new version needs to try out if the bug is fixed. It will have to wait. Since I gave a simple file that causes the issue and the command options I used perhaps someone there can try it out to verify if this bug is fixed or not with this new version. Thanks

[mastersans]

@tzirn renaming filename.vex to filename.json should work.

Thanks

[tzirn]

@mastersans OK I ran the following command:

cve-bin-tool -i test_SBOM.csv --vex-file test-triageFile.json -f html,csv --vex-output test-triage_out.json
<

This completed but did not fix the bug.
Please advise if these parameter/options are correct

I attached all the files this run created. The SBOM is the same as what was attached above and the triageFile is the same, just renamed to .json as you mentioned. So you can run it there very easily.

Note that the run with the new tool creates 2 "test-triage_out.json" files
1_test-triage_out.json
test-triage_out.json
output.cve-bin-tool.2024-09-05.09-12-12.csv
The HTML output can't be attached but it shows the same as the CSV output I can attach ( the uC/Lib vulnerability is still marked as "unexplored")

PLEASE ALSO NOTE: there appears to be a new bug with this test version in that the output report *.csv file no longer has the "comments" column filled out. It used to contain the reasoning given in the analysis --> detail section of the traigefile json/vex - now that column is empty. So no rationale is showing for the analysis stored in the "remarks" column.

[terriko]

Does the extension have to matter? If renaming works, I feel like we should just allow .vex as a possible extension.

[mastersans]

Let me see what i can find out, my linux machine got froze and won't work after that so i have to setup everything.

[terriko]

So, I've been thinking about whether we should change the planned release number. I'm not adverse to making this 4.0, but it seems like if we allow .vex and maybe turn the old flag into syntactic sugar for the new one with a deprecation warning, I think we can improve the backwards compatibility, so I'm going to go ahead and see how doable those two things are today.

New release is still likely to happen next week for a bunch of non-technical reasons, and I don't think we'll be able to fix everything in this thread (most of this is just going to have to happen in 3.4.1 or 4.0.1) but let me see about smoothing the transition to the new version.

[tzirn]

ok so just to summarize the issues on this thread:

1. main issue reported that the uC/Lib (id: uc/lib) vulnerability analysis data does not copy over after run through cve-bin-tool rev3.3 and the beta rev3.4rc1 (see original post and 9/5/24 post where I tested the new version and still see it)
2. the beta rev3.4rc1 has a new bug where the CSV output report AND the HTML output report does not fill out the Comments field from the triaged-file input. NOTE when I posted this I hadn't looked at the HTML output report but did today and they are both missing this data
3. a new problem I just noticed where the beta version added in a "see " comment that I dont have in my triage file. I have no idea where that came from (see CSV screen shot and 2nd HTML screen shot below)

@terriko Considering this 2nd and 3rd issues I can't see how you can put out this version since it losses the triage comments - it makes the output reports useless. See the 2 attachments I put in from my full report with all my SBOM data so you can see where it says its triaged but has no comments.

CSV report: Shows #1( last line), #2 (last column) and #3 (see green ?)

HTML report 1st capture: shows #2

HTML report 2nd capture: shows #1 (last row) and #3 (see green ?)

[terriko]

I'm doing the check to see if I need to change the versioning number first because if I switch this to be a 4.0 release it changes some internal process stuff that is easier for me if I know that it needs doing today vs next week. So I'm trying to get it done so I can make appropriate plans.

1. The original issue will not be fixed in the next release. It's not a regression and I don't currently know how to solve it.
2. We're ALREADY holding the 3.4 release because of the triage comments issue. (The release would otherwise have been today, a week after the pre-release.) I don't think it's going to take longer than next week to fix.
3. I'm pretty certain that this is an artifact of why the triage comments are broken so it should get fixed too. (I'm fairly certain the wrong comments field is getting propagated.)

Sorry about the confusion!