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

Meaning of "MITIGATED" where multiple CVE applies? #237

Open
Jwalker107 opened this issue Jan 5, 2022 · 3 comments
Open

Meaning of "MITIGATED" where multiple CVE applies? #237

Jwalker107 opened this issue Jan 5, 2022 · 3 comments
Assignees
Labels
discussion question or suggestion

Comments

@Jwalker107
Copy link

This has been a topic of discussion before, but as the number of CVEs has increased I wanted to ask clarity on the meaning of "MITIGATED". Taking an example JSON file report from Logpresso-Log4jscan-2.7.1, there is only a single result for each detected Log4j-core-2.x.jar file. Here's a sample for a version 2.9.1 result:

"reports": [
                {
                    "entry": "",
                    "product": "Log4j 2",
                    "version": "2.9.1",
                    "cve": "CVE-2021-44228",
                    "status": "MITIGATED",
                    "fixed": false,
                    "detected_at": "2022-01-05 11:28:21-0600"
                }
            ]

If I understand the CVE list correctly, a default Log4j2-core-2.9.1 should be vulnerable to the whole list of them -

  • CVE-2021-44228: Apache Log4j2 JNDI features do not protect against attacker controlled LDAP and other JNDI related endpoints. (fixed 2.15.0)
  • CVE-2021-45046: Apache Log4j2 Thread Context Lookup Pattern vulnerable to remote code execution in certain non-default configurations (fixed 2.16.0)
  • CVE-2021-45105: Apache Log4j2 does not always protect from infinite recursion in lookup evaluation (fixed 2.17.0)
  • CVE-2021-44832: Apache Log4j2 vulnerable to RCE via JDBC Appender when attacker controls configuration. (fixed 2.17.1)

This file was previously fixed using the "--fix" option in the scanner and should have the JndiLookup.class removed from it. I believe this makes it "mitigated" against CVE-2021-44228 and CVE-45056 and still "vulnerable" to CVE-2021-45105 and CVE-2021-44832

Since there is only one report line generated for each file, am I correct in understanding that

"reports": [
                {
                    "entry": "",
                    "product": "Log4j 2",
                    "version": "2.16.0",
                    "cve": "CVE-2021-45105",
                    "status": "VULNERABLE",
                    "fixed": false,
                    "detected_at": "2022-01-05 11:28:11-0600"
                }
....
"reports": [
                {
                    "entry": "",
                    "product": "Log4j 2",
                    "version": "2.16.0",
                    "cve": "CVE-2021-45105",
                    "status": "MITIGATED",
                    "fixed": false,
                    "detected_at": "2022-01-05 11:28:11-0600"
                }
            ]
@xeraph xeraph self-assigned this Jan 6, 2022
@xeraph xeraph added the discussion question or suggestion label Jan 6, 2022
@xeraph
Copy link
Contributor

xeraph commented Jan 6, 2022

@Jwalker107 Mitigated flag means --fix target doesn't exist.

if (entry.getName().equals(JNDI_LOOKUP_CLASS_PATH))
log4j2Mitigated = false;

Specific to 2.16.0 output, it's a little bit confusing as you said:

  • VULNERABLE means JAR has CVE-2021-45105 vulnerability and JndiLookup.class
  • MITIGATED means JAR has CVE-2021-45105 vulnerability but JndiLookup.class is eliminated.

// sort desc by cvss
String cve = "CVE-2021-44228";
if (v != null) {
if (v.getMinor() == 15)
cve = "CVE-2021-45046";
else if (version.startsWith("2.16.") || version.equals("2.12.2"))
cve = "CVE-2021-45105";
else if ((v.getMinor() == 17 && v.getPatch() == 0) || (v.getMinor() == 12 && v.getPatch() == 3)
|| (v.getMinor() == 3 && v.getPatch() == 1))
cve = "CVE-2021-44832";
}

It might be better to allow multiple vulnerability reports for one file..

@Jwalker107
Copy link
Author

Thank you, @xeraph, that clears up my question. I do think it would be useful to report on each CVE is still vulnerable to a particular instance, or at least the most severe that remains in the "Vulnerable" state after mitigation. I see some administrators who believe they are in the clear because their report shows "Mitigated" status and they are not understanding that they remain vulnerable to the later CVEs.

@doctore74
Copy link

Hi @xeraph ,

I agree. Our security colleagues prepare lists with the individual CVE findings in order to then provide them with mitigation measures. These lists are then sent to the teams. It would be much better if the lists were already pre-filtered in the output.
In our case (@thl-cmk) we would parse this information in checkmk afterwards.

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

No branches or pull requests

3 participants