mergebase / log4j-detector

A public open sourced tool. Log4J scanner that detects vulnerable Log4J versions (CVE-2021-44228, CVE-2021-45046, etc) on your file-system within any application. It is able to even find Log4J instances that are hidden several layers deep. Works on Linux, Windows, and Mac, and everywhere else Java runs, too! TAG_OS_TOOL, OWNER_KELLY, DC_PUBLIC
Other
635 stars 98 forks source link

Output fixing / adjustment #78

Open 1tft opened 2 years ago

1tft commented 2 years ago

Current output for log4j 2.x findings without JndiLookup.class is: _POTENTIALLY_SAFE_ (Did you remove JndiLookup.class?)_ I think _POTENTIALLY_SAFE_ is not correct any longer because log4j 2.x without JndiLookup.class is only _POTENTIALLY_OKAY_, because with removing JndiLookup.class you cant mitigate any CVE found after 2.15 version. Current (log4j-detector-2021.12.29.jar) output for findings regarding log4j-core-2.15.0.jar without JndiLookup.class: _log4j-core-2.15.0.jar contains Log4J-2.x <= 2.0-beta8 _POTENTIALLY_SAFE_ (Did you remove JndiLookup.class?)_ So its not correct any longer (since log4j 2.16 has been released).

There is another issue, its not really good to use status _OKAY_ and another status named _POTENTIALLY_OKAY_ because these are two different status but you cant differ/extract (via regex) simply these two status. For automatic evaluations it would be better to have two completely different status like: _OKAY_ and _POTENTIALLYOKAY_ or _POTENTIALLY-OKAY_

We use log4j-detector engine with an ansible playbook (execution) => elasticsearch (result storage) => grafana (result visualization/reporting). Thank you for providing such a professional scanner!

rgmz commented 2 years ago

There is another issue, its not really good to use status _OKAY_ and another status named _POTENTIALLY_OKAY_ because these are two different status but you cant differ/extract (via regex) simply these two status.

It should be possible. Can you share the regex you're using?

1tft commented 2 years ago

Hello rgmz, thank you for your prompt answer and a happy new year!

To get different status regarding (POTENTIALLY)_SAFE I use following regex:

/.*_POTENTIALLY_SAFE_.*/ /.*\s_SAFE_.*/

It is working for the most use cases, but because of using "\" at regex, there are problems with dynamic (templated) lucene queries inside Grafana. "\" has to be escaped and so query is not working in all situations. I can live with that, but its not optimal.

But its important that scanner does not report any longer "SAFE" for log4j archives with removed JndiLookup.class, because of CVE-2021-45105 and CVE-2021-44832 which cant mitigated with removing JndiLookup.class.