Not 100% because if OFF is used in an API call, as opposed to in a configuration file, it can mean turn off level filtering and log that event.
See https://logging.apache.org/log4j/2.x/manual/architecture.html Specifically: "LoggerConfigs will be assigned a Log Level <https://logging.apache.org/log4j/2.x/log4j-api/apidocs/org/apache/logging/log4j/Level.html>. The set of built-in levels includes ALL, TRACE, DEBUG, INFO, WARN, ERROR, FATAL, and OFF. Log4j 2 also supports custom log levels <https://logging.apache.org/log4j/2.x/manual/customloglevels.html>. Another mechanism for getting more granularity is to use Markers <https://logging.apache.org/log4j/2.x/log4j-api/api.html#Markers> instead. The OFF and ALL levels are not intended to be used on calls to the logging API. Specifying OFF in the configuration implies no logging events should match while specifying ALL would mean all events match, including custom events. However, OFF can be used on logging API calls in special cases where the event should always be logged regardless of the configuration. However, it is generally recommended that a Marker with a corresponding global Marker Filter be used instead." Gary On Mon, Dec 13, 2021 at 10:06 AM Sander, Uwe <uwe.san...@zeiss.com> wrote: > Hi all, > > I have seen multiple ways to mitigate the effects of CVE-2021-44228 > (Log4Shell) for different Log4J 2.x versions. One thing I have not seen is > to set the log level to OFF. This would effectively disable logging, of > course, but it might be a temporary mitigation that works for us. > > Can anyone confirm that setting the log level to OFF closes the attack > vector effectively? > > Thanks, > Uwe > > >
