-
Notifications
You must be signed in to change notification settings - Fork 173
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
Comments
@JStevens1855 Scanner does mark log4j 2.16.0 as vulnerable.
If you tries to fix it, scanner will refuse it like this:
Which scanner version do you use? |
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. |
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" |
@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? |
Yes. If scanner cannot detect log4j 2 version, it print potentially vulnerable.
IMHO, false positive is better than false nagative. I will resolve this issue with md5 detection. |
@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. |
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 Modify your local agent configuration file (search for the log_level parameter) (no restart is required) |
@JStevens1855 Would you send me that newrelic.jar file? you can change file extension to zip and upload here, or box.com sharing link. |
@xeraph I got still N/A for one file, maybe you can add the MD5 to on of the next versions.
|
@thl-cmk Oh, I missed hash for log4j 1.2.17 version. thank you! |
@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 works now for me THX!
|
@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. |
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.
The text was updated successfully, but these errors were encountered: