log4j-over-slf4j bridge identified as old log4j

[mergebase]

log4j-over-slf4j bridge identified as old log4j

[juliusmusseau]

Thanks for this feedback! I agree 100% that log4j-over-slf4j is NOT log4j.

Looks like testing for presence of "log4j/DailyRollingFileAppender.class" would work much better. :-)

I figured out a cute technique just now for quickly getting an overview of which class files are in which jar files (essentially a type of bitfield):

cat b/files api/files api/files l1/files l1/files l1/files l1/files l2/files l2/files l2/files l2/files l2/files l2/files l2/files l2/files | sort | uniq -c | sort -n | less -S

`
b = log4j-over-slf4j-1.7.32.jar
api = log4j-1.2-api (maintained by log4j2 project)
l1 = log4j-1.1.3
l2 = log4j-1.2.17

According to that approach "log4j/DailyRollingFileAppender.class" is only in l1 and l2.

[MarkvanOsch]

Same question here, how it this dependency to Log4j 1.x in here. I cannot find it.

log4j-over-slf4j-1.7.21.jar contains Log4J-1.x <= 1.2.17 OLD :-|

[MarkvanOsch]

Because log4j-over-slf4j is replacing log4j classes, I think the string path match does not work for this. "log4j/FileApppender.class" can be the same from log4j-over-slf4j and log4j libs.

[juliusmusseau]

Fixed. Such a small fix I'm not bothering to increment the version, and I just replaced current v2021.12.16 pre-built binary with this fix.

[MarkvanOsch]

Top, great effort! 👍

[rnaredl]

HI All, Great effort and many thanks.

could you please advise how much time it will take to complete the scan and generate the report.

[rnaredl]

HI All,
please advise how much time it will take to complete?
as my servers its taking longer time but its not writing anything other then first line like below.
-- github.com/mergebase/log4j-detector v2021.12.16 (by mergebase.com) analyzing paths (could take a while).
-- Note: specify the '--verbose' flag to have every file examined printed to STDERR.
/appl/dcvs3sc/backup/webServiceStub.war!/WEB-INF/lib/log4j-1.2.17.jar contains Log4J-1.x <= 1.2.17 OLD :-|

[juliusmusseau]

What version of the scanner are you using? How are you invoking it (e.g., as which user, and against which path)? How large are the disks you are scanning?

Are you including the "--verbose" flag? There is also an undocumented "--debug" flag you can add as well.

Here's my favourite way to run it (as root on a linux box)

time java -jar log4j-detector-2021.12.16.jar --verbose / > hits.txt

[rnaredl]

HI Team,
am running it under root user and am using 12.16 version.
i did not use verbose option .
let me try
Many thanks for the update.