cve-bin-tool supported

[beruhan]

The CVE Binary Tool helps you determine if your system includes known vulnerabilities. You can scan binaries for over 200 common, vulnerable components (openssl, libpng, libxml2, expat and others)。

[m-1-k-3]

Could you please provide further details:

• Link to tool
• How to install
• How to use
• Comparison to the current EMBA results

Thanks
MIke

[beruhan]

Link to tool: https://github.com/intel/cve-bin-tool/tree/main
doc: https://cve-bin-tool.readthedocs.io/en/latest/
Currently, no comparison has been made with the system's built-in component vulnerability scanning feature. However, according to the official description, integrating this feature is expected to bring some level of capability improvement.

[m-1-k-3]

Looks very promising. Nevertheless, a benchmark and further comparison would be very useful as the current EMBA integration checks for over 700 binary identifiers. As far as I can see they have a quite understandable Regex integration for all of the search patterns. See here https://github.com/intel/cve-bin-tool/blob/main/cve_bin_tool/checkers/asterisk.py
We could also check which patterns are currently not available in EMBA and port them to the EMBA environment instead of integrating the complete tool.

[torabi12]

I decrypted a D-Link DIR-878 firmware and made a compare test with cve-bin-tool and emba for it.
I used this tool to get the readable bin file:

https://github.com/0xricksanchez/dlink-decrypt

This would be the cve-bin-tool outcome:

cve_report DIR878_FW1.30B08_decrypted.pdf

and emba provided these findings:

I used this file for input:
http://legacyfiles.us.dlink.com/DIR-878/REVA/Firmware/DIR-878_REVA_FIRMWARE_v1.30B08.zip

cve-bin-tool was extreamly fast, it took just a few minutes to go through the filesystem, emba default scan profile lasted for 01:08:45, but it was also an acceptable run. :)

[m-1-k-3]

a quick check based only on the filenames for the checking patterns showed that EMBA supports already at least 139 patterns from cve-bin-tool (371 checks at all):

for file in cve_bin_tool/checkers/*.py; do fname=$(basename -s .py $file); echo $fname >> ~/Downloads/cve_bin_tool_all.txt; echo "testing $fname"; if grep -q $fname ~/firmware-analysis/emba_forked/config/bin_version_strings.cfg; then echo $fname >> ~/Downloads/cve_bin_tool_in_emba.txt; fi; done


┌──(m1k3㉿kali-emba)-[~/github-repos/cve-bin-tool]
└─$ wc -l ~/Downloads/cve_bin_tool_all.txt                                                    
371 /home/m1k3/Downloads/cve_bin_tool_all.txt
                                                                                                                                                                                                                                            
┌──(m1k3㉿kali-emba)-[~/github-repos/cve-bin-tool]
└─$ wc -l ~/Downloads/cve_bin_tool_in_emba.txt                                                
139 /home/m1k3/Downloads/cve_bin_tool_in_emba.txt

[m-1-k-3]

Thank you for checking:

cve-bin-tool was extreamly fast, it took just a few minutes to go through the filesystem, emba default scan profile lasted for 01:08:45, but it was also an acceptable run. :)

as cve-bin-tool is only checking for system components we need to adjust the EMBA run a bit more with only running the scanning modules s06, s08, s09, s24, s25. I do not think that we will be as fast ... but a bit faster compared to the default scan ;)

[torabi12]

I did a compare tests for the original DIR_878_FW1.30B08.bin file and the decrypted version binary with emba.

The original use "SHRS" encryption and I got this:

and the decrypted file version in emba dropped some more findings:

but almost identical.
The powerful thing is that emba can unpack/decrypt the file, while cve-bin-tool can only use it if the tester manually decompiles the firmware file back to the file system.

I used this cve-bin-tool command syntax recently:

$ cve-bin-tool /path/to/decrypted/filesystem --format pdf --output-file ~/cve_report --nvd-api-key MYAPI_KEY

[m-1-k-3]

My SBOM Testfirmware results:

cve-bin-tool:
Runtime: ~70mins

└─$ cat cve-bin-tool.json | jq -r '.components[] | "\(.name) \(.version)"' | sort -u | wc -l
609

EMBA:
Runtime: ~3:50h

└─$ cat ~/firmware-analysis/emba_logs_test1/SBOM/EMBA_cyclonedx_sbom.json | jq -r '.components[] | "\(.name) \(.version)"' | sort -u | grep -v "null" | wc -l
1669

Syft
Runtime: 10 secs

└─$ cat ~/Downloads/SE_SBOM-Tests/testimage-small-syft-sbom.json | jq -r '.components[] | "\(.name) \(.version)"' | sort -u| wc -l                  
1647

The thing I like in cve-bin-tool is that the vulnerability check is so damn fast. I will do a further evaluation if we can use the sqlite database from them for our own vulnearbility identification.

[m-1-k-3]

looks as an integration of this tool could be easily realized via the csv2cve mechanism:

└─$ cat ~/Downloads/test.csv
busybox,busybox,1.14.1

└─$ python3 ./cve_bin_tool/cli.py -i ~/Downloads/test.csv --offline -f csv -o /home/m1k3/Downloads/asdf --metrics

After the run we have in /home/m1k3/Downloads/asdf.csv all the needed data.

I think with this mechanism we need to split every component in one csv input file and let cve-bin-tool run in threaded mode.

The main issue I have seen is that in some cases we look for unknown or multiple vendor entries which is in our current implementation just a * in our regex. I have not found a way how cve-bin-tool can handle this case.

Any further suggestions?

[hands0meware]

Like wise. I can second that cve-bin-tool wins the time race here !
EMBA would be so much better if it ran under 15 mins. (integrating cve-bin-tool in EMBA would be a nightmare to integrate somewhere in between)
I tested EMBA for a given FS extracted from a rootfs.ext4 i have and used cve-bin-tool.
Approximately 650 binaries all ELF and shared libs. (small in size and not bigger than 2 or 3MB individually)
EMBA was still running for more than 7 hours.
CVE bin tool finished in like roughly 10 mins.
As someone mentioned in a previous issue #1355
I also run a pretty strong Linux machine so that's not the problem.
EMBA has so many more features like emulation and reversing, at one point i saw it trying to run radare like scripts or syntax on some binaries - don't know where it came from.

I think the if emba is run without any profile arguments, it should pick the one that the most basic and runs faster(like a quick scan) than being the other way around. Even if i pick a smaller set of scans it still takes a long time.
1 hour is an eternity. Maybe there can be some worker thread based distribution of analyzers to improve the efficiency.

Besides, what is the purpose of the tool if it takes blindingly long time to run, it really not scalable. Reminds me of the old days to run make on the code and come back an hour later to see what went wrong.

It is an excellent tool with a lot of features, but i feel that it needs some restructuring and speed !

[m-1-k-3]

Like wise. I can second that cve-bin-tool wins the time race here ! EMBA would be so much better if it ran under 15 mins. (integrating cve-bin-tool in EMBA would be a nightmare to integrate somewhere in between) I tested EMBA for a given FS extracted from a rootfs.ext4 i have and used cve-bin-tool. Approximately 650 binaries all ELF and shared libs. (small in size and not bigger than 2 or 3MB individually) EMBA was still running for more than 7 hours. CVE bin tool finished in like roughly 10 mins.

cve-bin-tool is a SBOM tool. EMBA is a complete firmware analysis framework. So, comparing apples with oranges is always difficult. At least you need to use the right scanning-profile like one of the SBOM profiles. And also in such case you are comparing one tool with extraction with one that is not able to handle extraction and always needs pre-processing. Additionally, EMBA will check multiple package-managers and more binary identifiers (see results here)

As someone mentioned in a previous issue #1355 I also run a pretty strong Linux machine so that's not the problem. EMBA has so many more features like emulation and reversing, at one point i saw it trying to run radare like scripts or syntax on some binaries - don't know where it came from.

use the right scanning-profile or enable only the modules you need.

I think the if emba is run without any profile arguments, it should pick the one that the most basic and runs faster(like a quick scan) than being the other way around. Even if i pick a smaller set of scans it still takes a long time. 1 hour is an eternity. Maybe there can be some worker thread based distribution of analyzers to improve the efficiency.

You have a different use-case as I. For addressing different use-cases we have scanning-profiles. Use them and they will make you happy :)

Besides, what is the purpose of the tool if it takes blindingly long time to run, it really not scalable. Reminds me of the old days to run make on the code and come back an hour later to see what went wrong.

It is an excellent tool with a lot of features, but i feel that it needs some restructuring and speed !

You are welcome to improve it -> PR can be submitted here. Make it faster and make it better ... you can be part of it!