Remediation Needed from Avast - Log4J Found in On-Prem MC v 7.29.968

[bob3160]

@matthew343 post:12

@bob3160 post:9

I’ve again alerted Avast.

Thank you Bob, I did engage support as well, response was slow and seemed like a canned response.

Avast has already responded to the alert I sent them about your concern,

@Nevik post:10

Hello, I’m from the Avast development team. Our on-premise console doesn’t contain any artifact that would be vulnerable to the Log4Shell (CVE-2021-44228). The file sentry-1.7.14.jar is a false positive report. Based on the output that you have provided, it looks that you are using tool that is based on script from https://github.com/datto/log4shell-tool. I’ve inspected the sources of the tool and the tool is trying to locate the problematic class org.apache.logging.log4j.core.lookup.JndiLookup inside jar files, but it is not doing it correctly. It is just looking for class with name JndiLookup and not taking into account the java package. The file sentry-1.7.14.jar does not contain the vulnerable class, but it contains io.sentry.config.JndiLookup, which is a java class with the same name, but in different java package and with different content.

There is nothing wrong with the JNDI technology itself (and JndiLookup). Issue is in the Log4j library that it can do (under certain circumstances) a request to external (attacker) servers using JNDI lookup, while writing the log messages. Moreover, even sentry is not active in the on-premise console and it is just a transitive compile dependency (no JNDI lookups are made).