Avast WEBforum
Business Products => Avast Business => On-Premise Management Console & Clients => Topic started by: matthew343 on December 15, 2021, 07:11:33 PM
-
Hi There,
We have detected the Avast Management console v 7.29.968 contains a vulnerable version of log4j, will Avast be publishing an update to remediate this? Many of our other software providers distributed updates within 24 hours
-
I've alerted Avast of your problem.
Let's see if that helps.
-
analysis in prog, will come soon..
-
On-premise console is not affected by the security issue.
It is using Logback (https://logback.qos.ch/) library for logging (configured in C:\Program Files\AVAST Software\Management Console\console\config\logback.xml, C:\Program Files\AVG\Management Console\console\config\logback.xml), not Log4j.
more: logging libraries in java have typically 2 parts - API part that defines the syntax for expressing the "intent" that you want to write some log message and then the implementation of the logging mechanism itself (writing of log messages to files, sending them over network, ...). The vulnerability is in the implementation part of Log4j (file log4j-core.jar), there is no security problem in the API artifacts (log4j-api.jar)
-
This is confirmed analysis from Avast development.
On-premise console is not affected by the security issue.
It is using Logback (https://logback.qos.ch/) library for logging (configured in C:\Program Files\AVAST Software\Management Console\console\config\logback.xml, C:\Program Files\AVG\Management Console\console\config\logback.xml), not Log4j.
more: logging libraries in java have typically 2 parts - API part that defines the syntax for expressing the "intent" that you want to write some log message and then the implementation of the logging mechanism itself (writing of log messages to files, sending them over network, ...). The vulnerability is in the implementation part of Log4j (file log4j-core.jar), there is no security problem in the API artifacts (log4j-api.jar)
-
Can I confirm here in public on your forum... Does the on-prem Avast management console contain a log4j binary version < 2.16? If not, does Avast plan to release a hotfix replacing existing log4j binaries with a version >= 2.16?
-
I want to share I have run a second tool that feels the sentry-1.7.14.jar file included in the Avast MC console installation is vulnerable. Just mentioning I have two scanning tools flagging the file.
-
I concur with Matt. Avast you need to address this!
-
I've again alerted Avast.
-
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).
-
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?
-
I've again alerted Avast.
Thank you Bob, I did engage support as well, response was slow and seemed like a canned response.
-
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,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 (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).
-
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.