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

Clarifications for "Potentially Vulnerable" for CVE-2021-44228 #266

Open
JStevens1855 opened this issue Feb 1, 2022 · 13 comments
Open

Clarifications for "Potentially Vulnerable" for CVE-2021-44228 #266

JStevens1855 opened this issue Feb 1, 2022 · 13 comments
Assignees
Labels
discussion question or suggestion patch released

Comments

@JStevens1855
Copy link

I was hoping you might be able to clarify for me what would make CVE-2021-45105 show potentially vulnerable rather than vulnerable or mitigated if it has Log4 2.16.0? I didn't think there were classes that could be removed to mitigate that CVE.

This came up when inspecting some of the results so I wanted to clarify what cases would fall into that bucket.

@xeraph xeraph self-assigned this Feb 1, 2022
@xeraph xeraph added the discussion question or suggestion label Feb 1, 2022
@xeraph
Copy link
Contributor

xeraph commented Feb 1, 2022

@JStevens1855 Scanner does mark log4j 2.16.0 as vulnerable.

cmd> java -jar logpresso-log4j2-scan-2.8.1.jar d:\tmp2\log4j-core-2.16.0.jar
Logpresso CVE-2021-44228 Vulnerability Scanner 2.8.1 (2022-01-27)
Scanning directory: d:\tmp2\log4j-core-2.16.0.jar
[*] Found CVE-2021-45105 (log4j 2.x) vulnerability in d:\tmp2\log4j-core-2.16.0.jar, log4j 2.16.0

Scanned 0 directories and 1 files
Found 1 vulnerable files
Found 0 potentially vulnerable files
Found 0 mitigated files
Completed in 0.25 seconds

If you tries to fix it, scanner will refuse it like this:

cmd> java -jar logpresso-log4j2-scan-2.8.1.jar --force-fix d:\tmp2\log4j-core-2.16.0.jar
Logpresso CVE-2021-44228 Vulnerability Scanner 2.8.1 (2022-01-27)
Scanning directory: d:\tmp2\log4j-core-2.16.0.jar
[*] Found CVE-2021-45105 (log4j 2.x) vulnerability in d:\tmp2\log4j-core-2.16.0.jar, log4j 2.16.0

Cannot fix CVE-2021-45105, Upgrade it: d:\tmp2\log4j-core-2.16.0.jar

Scanned 0 directories and 1 files
Found 1 vulnerable files
Found 0 potentially vulnerable files
Found 0 mitigated files
Fixed 0 vulnerable log4j2 files and potentially vulnerable log4j1 files
Completed in 0.09 seconds

Which scanner version do you use?

@JStevens1855
Copy link
Author

So I apologize I must have been mixing up my reports. the 4105 was on an older scan and wasn't identified as potentially vulnerable using 2.7.1 scanner, however I do have files what were scanned with the 2.1.1 jar that come back with 44228 as Potentially_vulnerable. I would think that if the jndi class was removed, then this file would change to mitigated rather than potentially vulnerable. Could it be that it can't determine the version for validation (maybe why it's showing n/a instead of a version). It looks like I have quite a few of these for 44228.
Log4j 2 | N/A | CVE-2021-44228 | POTENTIALLY_VULNERABLE |   | 1/30/2022 3:21
I am going to rescan with 2.8.1 to see if it it comes back different. I thought i had already updated the scanner version for windows but I guess I only updated the Linux scanner version.
****By the way thank you for all the work you have put into this project. The work really is amazing and appreciated.

@JStevens1855
Copy link
Author

Yeah not sure why but rescanned with 2.8.1 and the file came back with "Log4j 2","N/A","CVE-2021-44228","POTENTIALLY_VULNERABLE","","2022-02-01 10:39:40"
Is this the behavior if it can't identify what the log4j version is?

@JStevens1855 JStevens1855 changed the title Clarifications for "Potentially Vulnerable" for CVE-2021-45105 Clarifications for "Potentially Vulnerable" for CVE-2021-44228 Feb 1, 2022
@JStevens1855
Copy link
Author

@xeraph - I need to cross reference some of these apps that i'm seeing this on but I'm thinking maybe some were remediated by setting the Log_level to off. Would that scenario be a reason that it might show potentially_vulnerable rather than vulnerable or mitigated?

@xeraph
Copy link
Contributor

xeraph commented Feb 3, 2022

@JStevens1855

Yeah not sure why but rescanned with 2.8.1 and the file came back with "Log4j 2","N/A","CVE-2021-44228","POTENTIALLY_VULNERABLE","","2022-02-01 10:39:40" Is this the behavior if it can't identify what the log4j version is?

Yes. If scanner cannot detect log4j 2 version, it print potentially vulnerable.

@xeraph - I need to cross reference some of these apps that i'm seeing this on but I'm thinking maybe some were remediated by setting the Log_level to off. Would that scenario be a reason that it might show potentially_vulnerable rather than vulnerable or mitigated?

IMHO, false positive is better than false nagative. I will resolve this issue with md5 detection.

@xeraph
Copy link
Contributor

xeraph commented Feb 3, 2022

@JStevens1855 Would you test v2.9.1 release? I added 55 MD5 hashes to resolve this issue. It accurately detect Log4j 2.x version without pom.properties file.

@JStevens1855
Copy link
Author

Unfortunately after scanning with 2.9.1 the results were the same. I attached a screenshot of the csv details, hopefully it comes through for you
It looks like we have at minimum 3 applications on numerous servers that are coming up "Potentially_Vulnerable" for CVE-2021-44228. I'm not sure why it's not able to identify the Log4j version still but I was able to get ahold of new relic instructions for temporary "remediation" they did for the new relic application and i'm guessing that it just likely wouldn't be able to identify that it we remediated. Here is the temporary remediation, but i'm guessing because of the method for remediation it probably just be a false positive going forward.
You can set your Java agent logging level to OFF to remediate CVE-2021-44228. To do this, use any of the following options:

Modify your local agent configuration file (search for the log_level parameter) (no restart is required)
Define the newrelic.config.log_level=OFF system property (restart required)
Set the NEW_RELIC_LOG_LEVEL=OFF environment variable (restart required)
image

@xeraph
Copy link
Contributor

xeraph commented Feb 4, 2022

@JStevens1855 Would you send me that newrelic.jar file? you can change file extension to zip and upload here, or box.com sharing link.

@thl-cmk
Copy link

thl-cmk commented Feb 5, 2022

@xeraph I got still N/A for one file, maybe you can add the MD5 to on of the next versions.

$  sudo /usr/lib/check_mk_agent/bin/log4j2-scan  --scan-logback --scan-log4j1 /usr/share/java/log4j-1.2-1.2.17.jar

Logpresso CVE-2021-44228 Vulnerability Scanner 2.9.1 (2022-02-03)
[?] Found CVE-2021-4104  (log4j 1.2) vulnerability in /usr/share/java/log4j-1.2-1.2.17.jar, log4j N/A

log4j-1.2-1.2.17.zip

@xeraph
Copy link
Contributor

xeraph commented Feb 5, 2022

@thl-cmk Oh, I missed hash for log4j 1.2.17 version. thank you!

@xeraph
Copy link
Contributor

xeraph commented Feb 5, 2022

@JStevens1855 Found newrelic.jar from https://download.newrelic.com/newrelic/java-agent/newrelic-agent/current/newrelic.jar and added md5 hash. Would you test v2.9.2 release?

@thl-cmk
Copy link

thl-cmk commented Feb 5, 2022

@xeraph works now for me THX!

$ sudo /usr/lib/check_mk_agent/bin/log4j2-scan  --scan-logback --scan-log4j1 /usr/share/java/log4j-1.2-1.2.17.jar
Logpresso CVE-2021-44228 Vulnerability Scanner 2.9.2 (2022-02-06)
[?] Found CVE-2021-4104  (log4j 1.2) vulnerability in /usr/share/java/log4j-1.2-1.2.17.jar, log4j 1.2.17

@JStevens1855
Copy link
Author

@JStevens1855 Found newrelic.jar from https://download.newrelic.com/newrelic/java-agent/newrelic-agent/current/newrelic.jar and added md5 hash. Would you test v2.9.2 release?

@xeraph Thanks for all of your effort on this one. I am glad you were able to find a current copy of the newrelic.jar, however I re-ran 2.9.2 one one server and it still came back as potentially vulnerable. Unfortunately I don't believe we will get approval to upload the various newrelic.jar files and I believe what we are going to see is that they might not all be the current version and I would imagine different versions would have unique md5 hashes. We currently have 500+ instances of New.relic.jar in various applications. For the time being we will accept them as false positives and work with the application owner to verify remediation and upgrade path. I appreciate your quick response and investigation. I might have to see if I can make an additional step to identify the MD5 hash or checksum of these jar files. There might be a way to match them to a newrelic jar version.

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

No branches or pull requests

3 participants