Potentially vulnerable

[AlexMilotin]

Hi,

With all the new changed and new CVE i ended up a bit confused. What does Potentially Vulnerable would really mean ? Don't get me wrong from having ~900 vulnerable files in a 450 servers infrastructure i ended up now with 1621 Potentially vulnerable. Is it that the log4j version cannot be determined ?

Also for the rest of the findings regards Log4j 1.2 (which are not marked as Potentially) at the beginning of the string we have [?] and not [*] as for the rest. I really appreciate the work and effort you put in this tool, but i really want to understand the differences, just to ensure when "managers" come to me asking, i can explain them in a more intelligible way:)

[ChKemper]

Hi,

oh yes - there are a lot of CVE's ans versions...

When the Scanner can read the exact Version of log4j it can check if this version is vulnerable. So you get it marked as vulnerable. If the scanner could not read the pom.properties (where the exact version is placed) and in the JAR contains a class which is typically for log4j it is marked as Potentially Vulnerable. The Scanner tries to determine if there is a version of log4j which is not the official JAR from Apache.

Log4j 1.x is always marked as Potentially Vulnerable because it is only vulnerable if you use a special configuration (e.g. JMSAppender). A scanner cannot check the configuration files because you can name it individually or change the configuration programmatically.

Hope this makes it a little bit clearer.

[AlexMilotin]

So basically all those that do not have the pom.properties, right ?

For example, the below doesn't have it [?] Found CVE-2021-4104 (log4j 1.2) vulnerability in E:\CA0000965\CA0000965_W7\CAx\App\CR5000\DOME\lib\log4j-1.2.14.jar, log4j N/A - potentially vulnerable

But i was able to find a the JMSAppender.class as file in E:\CA0000965\CA0000965_W7\CAx\App\CR5000\DOME\lib\log4j-1.2.14\org\apache\log4j\net

Is this the reason why it was found as possible vulnerable ?

And how should we treat them ?

[xeraph]

@AlexMilotin all log4j 1.2.x versions are potentially vulnerables. (although it is hard to meet certain exploit conditions) If you don't want to detect log4j1 vulnerabilities, do not use --scan-log4j1. However, if you can't ensure application is using JMSAppender, it is still potentially vulnerable.

If application doesn't use JMS (Java Message Service) logging or socket server based logging, it is safe and can be ignored. (that's why scanner marked it as potentially vulnerable)

If you don't know application's configuration and want to ensure safety, --fix it. However, I recommend you to consult with engineer who manages application before applying mitigation.

[AlexMilotin]

This is are the exact explanation i was seeking for, thank you a tone guys. I would never be able to offer you the gratitude you deserve for this.