Mitigation Steps: 1. Login to the appliance via SSH as the user "toor".
2. The log4j2 libraries under the /loglogic directory are used internally by the LMI/EVA only. Run the following command to verify the existence of the vulnerable classes in the log4j2 library, which will return the name of the class in the library. If the command returns the vulnerable class names, proceed to step 3, otherwise you do not need to follow the steps in this document:
$ find /loglogic -name log4j-core* | xargs -I{} zip -sf {} | grep "JndiLookup.class"Example output:
org/apache/logging/log4j/core/lookup/JndiLookup.class
...
3. Stop all engines by issuing command:
$ mtask stop4. Run the following command to remove the vulnerable classes in the library to mitigate the issue:
$ find /loglogic -name log4j-core* | xargs -I{} zip -q -d {} org/apache/logging/log4j/core/lookup/JndiLookup.class5. Run the command in step 2 again to verify the removal of the vulnerable classes in the library.
6. Reboot the appliances to cause the change to take effect.
7. After rebooting login to the appliance via SSH again as the user "toor", run the following command to make sure all engines (services) are in RUNNING state, which indicates the appliance is back into full production.
$ watchqueueAdditional Notes:
- TIBCO Loglogic product team will release a service pack soon to address CVE-2021-44228 and CVE-2021-45046 vulnerabilities.
- TIBCO Loglogic Log Management Intelligence versions 6.3.0 and earlier are not impacted by CVE-2021-44228 and CVE-2021-45046 issues. For more details see https://github.com/apache/logging-log4j2/pull/608#issuecomment-991723301