You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I tried installing ActiveMQ 5.16.4 which comes with reload4j-1.2.19, now running the detector shows the following output:
-- github.com/mergebase/log4j-detector v2021.12.29 (by mergebase.com) analyzing paths (could take a while).
-- Note: specify the '--verbose' flag to have every file examined printed to STDERR.
activemq-all-5.16.4.jar contains Log4J-1.x <= 1.2.17 _OLD_
As per raising the issue with the AMQ team, we received the following comment:
The Log4J transitive dependency from Zookeeper related bits were excluded (directly or via dependencyManagement) and reload4j was added to activemq-partition as a dependency to serve in their place during AMQ-8472. The classes included in activemq-all thus should be those from reload4j, which necessarily uses the same org.apache.log4j namespace to serve their intent to act as a substitute for Log4j.
After some inspection, I figured that the log4j-detector jar is doing a check with the same namespace as it is in log4j-1.x hence seeing the issue:
private static final String FILE_OLD_LOG4J = "log4j/DailyRollingFileAppender.".toLowerCase(Locale.ROOT);
Since reload4j has resolved the vulnerability as seen in log4j-1.x but uses the same namespace, I believe the condition check for checking the existence of log4j-1.x shall be improved here or else all reload4j jars will be wrongly detected as vulnerable.
The text was updated successfully, but these errors were encountered:
Hi,
I tried installing ActiveMQ 5.16.4 which comes with reload4j-1.2.19, now running the detector shows the following output:
As per raising the issue with the AMQ team, we received the following comment:
After some inspection, I figured that the log4j-detector jar is doing a check with the same namespace as it is in log4j-1.x hence seeing the issue:
Since reload4j has resolved the vulnerability as seen in log4j-1.x but uses the same namespace, I believe the condition check for checking the existence of log4j-1.x shall be improved here or else all reload4j jars will be wrongly detected as vulnerable.
The text was updated successfully, but these errors were encountered: