Automated Impact Assessment

Summary

Filter out CVEs that are not applicable to your uploaded firmware and focus on true positives and relevant vulnerabilities. CVEs are excluded according to a set of rules that can target either generic components or the Linux kernel.

To use this feature, make sure the Show only confirmed matching CVEs checkbox is enabled when viewing either the global or a firmware-specific CVE table.

Automated Impact Assessment analyzes extracted firmware files to identify and hide non-exploitable CVEs. Essentially, this feature acts as a filter, allowing you to focus on relevant vulnerabilities. A CVE is deemed "non-exploitable" if:

1. The affected version is different from the one in your firmware.
2. The vulnerability affects a feature or module that was not compiled in.
3. The vulnerability affects a feature that is not explicitly used by the firmware.

For example, if a CVE is only exploitable over Bluetooth, but your firmware runs on a Linux kernel without a Bluetooth submodule, the platform automatically filters out this CVE.

How to use it

Automated Impact Assessment is enabled by default for all uploaded firmware, but you can turn it on and off with the Show only confirmed matching CVEs checkbox in either the CVE page of Firmware analysis view or the Global CVE page.

The feature assigns each CVE a match score:

1. Positive score: the CVE is relevant to your firmware.
2. Negative score: the CVE is considered non-exploitable.

A higher absolute score, whether positive or negative, indicates greater confidence in the assessment.

A match score of 0 means either that the negative and positive scores cancel each other out, or that the platform is unsure about the particular CVE and therefore cannot give it a score.

When Automated Impact Assessment is enabled, only CVEs with a score of -2 or higher are displayed in the CVE tables. This ensures that potentially relevant vulnerabilities are not lost, while those least likely to apply are filtered out.

Note

Compliance checkers ignore CVEs with a negative score when calculating whether a compliance provision has been violated or not.

See the Match evidences section at the end of a CVE entry for details on how the match score was calculated and for the evidence behind the score and the decision:

How it works

Automated impact assessment uses a rule-based system to evaluate CVEs. If a rule applies to a CVE, we add a positive match score. If a rule does not apply to the CVE, or the rule is designed in such a way that it leads to a negative result, the CVE gets a negative score.

You can check the total score of all rules applied in the Match score column. For a detailed breakdown, see the Match evidences section.

A CVE rule can either be:

1. Automatically generated based on the CVEs description.
2. Manually created by ONEKEY security analysts.

The platform further distinguishes between two types of rules:

• General component rules.
• Linux kernel-specific rules.

General component rules

For general components, ONEKEY identifies and analyzes:

• The file names, strings, function imports, and binary usage within the firmware files.
• The target architecture (for example, x86, ARM).
• The CVE summary.

For CVEs with manually created rules, the platform runs 2-5 different checks to ensure accurate detection.

Note

To make sure that the CVE database is up-to-date, we perform a CVE database update every few hours. That is why if you have Monitoring enabled, you may notice some CVEs come and go with each run.

Linux kernel rules

Why does the Linux kernel have special rules?

The Linux kernel is extensive and has numerous versions, making it responsible for most of the CVEs in a firmware.

The platform uses a special approach to assess CVE relevance in Linux kernels on top of running the same check as with general components:

1. It extracts all kernels and their associated modules from the firmware and identifies the Symbols.
2. It then maps each kernel symbol (version-specific) to its corresponding source files in our database.
3. Finally, it analyzes kernel modules, specifically examining ELF files to identify the symbols.

ONEKEY compares the extracted data with the rules, and if there is a match, it gives the CVE a positive score.

Examples

CVE impacting a firmware

CVE-2022-48839 has a positive match score of 100, indicating a high likelihood that this vulnerability affects the uploaded firmware:

To understand how ONEKEY arrived at this conclusion, click on the CVE and navigate to the Match evidences section:

• Match on symbols: there is a match with a specific symbol or function within the kernel.
• Match on source files: the identified vulnerability is located in a source file within the kernel.
• Match on source files by symbol: the vulnerability is identified in a source file (by mapping the vulnerable function to the source file) within the kernel.

Based on the combination of these three match types, there is a strong case that the vulnerability is present in the firmware.

CVE not impacting a firmware

CVE-2022-48845 has a negative score of -147, indicating a low likelihood that this vulnerability affects the uploaded firmware:

Note

To list CVEs with a negative match score, disable the Show only confirmed matching CVEs checkbox.

• No match on architecture: the CVE is not relevant as it does not affect the specific architecture of the firmware.
• No match on source files: the identified vulnerability is not found within the specific source files, so the particular file is not affected by the vulnerability described in the CVE.
• No match on symbols: the specific symbols within the codebase are not associated with the identified vulnerability.
• Match on source files by symbol: there is a match with specific symbols within particular source files.

Based on the combination of these four match types, both positive and negative, there is a strong case that the vulnerability described by the CVE does not affect the uploaded firmware.