Moreover, even sentry is not active in the on-premise console and it is just a transitive compile dependency (no JNDI lookups are made).
Hi There, is it safe for me to delete the sentry-1.7.14.jar then? I assume since what we install is a fully compiled application, the transitive compile dependency is not necessary on the end user's device. Maybe Avast does not need to include it in the first place?
So, I stopped the Avast management console service, renamed the sentry-1.7.14.jar to sentry-1.7.14.backup then restarted the Avast MC service. This caused the web browser to the MC to become unresponsive, I assume because it could no longer locate the sentry jar file.
Next I stopped Avast Management Console service once again, and renamed the sentry-1.7.14.jar to sentry-1.7.14.zip and opened it in winzip, and removed the jndi.class file. I then named it back to sentry-1.7.14.jar and started the Avast Management Console Service. The web browser interface stayed stable in this case, and now the variety of detection tools for log4j no longer find an issue with avast.
For me, the way to get a pass from such tools while maintaining stability in the Avast MC was to remove the jndilookup.class from the sentry-1.7.14.jar file YMMV
While I am definitely hearing Avast's position on the matter, I have no way of independently verifying the validity of their position and would rather not take the chance. This was the only server/application that I've continued to have an issue with log4j found as present on the system where the vendor did not provide an update or patch.