The safest thing to do is to upgrade Log4j to a safe version, or remove the JndiLookup class from the log4j-core jar. The reason these measures are insufficient is that, in addition to the Thread Context attack vector mentioned above, there are still code paths in Log4j where message lookups could occur: known examples are applications that use Logger.printf("%s", userInput), or applications that use a custom message factory, where the resulting messages do not implement StringBuilderFormattable. Ensure Domain Accounts follows the least privilege principle and ensure Two-Factor authentication is enabled on all Business Email Accounts. Ensure VMware Horizon servers are updated with the latest security patches. Other insufficient mitigation measures are: setting system property log4j2.formatMsgNoLookups or environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true for releases >= 2.10, or modifying the logging configuration to disable message lookups with %m for releases >= 2.7 and <= 2.14.1. Ensure to patch Log4j to 2.3.2 (for Java 6), 2.12.4 (for Java 7), or 2.17.1 (for Java 8 and later).
This page previously mentioned other mitigation measures, but we discovered that these measures only limit exposure while leaving some attack vectors open. u/lost_signal tagged so someone from vmware sees this if not aware already. Came to this thread to ask the same question.
0 kommentar(er)
