[
https://issues.apache.org/jira/browse/LOG4J2-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17463803#comment-17463803
]
Christoph Grimm edited comment on LOG4J2-3221 at 12/22/21, 1:21 PM:
--------------------------------------------------------------------
I am aware that the preferred fix is to either upgrade to a newer log4j2
version or to remove the JndiLookup class from the package.
There are situations however, where this takes time and/or the respective team
resources are not available to get such a modification implemented and
regression tested for a short term production deployment.
As a kind of a "last resort" I came up with some additional idea. It is similar
to removing the JndiLookup class, but what one could do instead is to force
another version of that class to be loaded.
In environments where you have control over the java launch statement you can
create your own version of the JndiLookup class, which simply does "nothing",
instead of doing a lookup and include the same in the boot class path via
"-Xbootclasspath/a", which will force it to be used even in case of WebLogic
config entries like "prefer-web-inf-classes"
You need to consider some special aspect if you do this however:
You cannot make the class extend "AbstractLookup" or implement "StrLookup"
because this would create a class loader mess up (something like
"java.lang.LinkageError: loader constraint violation") in certain situations.
Therefore you what you will able to create is some "half-baked" class that
will fail to be loaded with a class cast exception looking like this in the log:
"JNDI lookup class is not available because this JRE does not support JNDI.
JNDI string lookups will not be available, continuing configuration. Ignoring
java.lang.ClassCastException: class
org.apache.logging.log4j.core.lookup.JndiLookup"
But the end justifies the means and since log4j is just complaining but not
failing on this exception I would see the above as a viable short term fix for
scenarios where you cannot touch the deployment build itself (I did validate
the same on a local Tomcat).
Of course in the longer run the remediation should be upgrading to a newer
version, re-build, re-test and redeploy ones whole application.
It would be great to get your thoughts on this, particularly if I have missed
anything substantial.
was (Author: JIRAUSER282467):
I am aware that the preferred fix is to either upgrade to a newer log4j2
version or to remove the JndiLookup class from the package.
There are situations however, where this takes time and/or the respective team
resources are not available to get such a modification implemented and
regression tested for a short term production deployment.
As a kind of a "last resort" I came up with some additional idea. It is similar
to removing the JndiLookup class, but one could do instead is to force another
version of that class to be loaded.
In environments where you have control over the java statement you can create
your own version of the JndiLookup class, which simply does "nothing", instead
of doing a lookup and include the same in the boot class path via
"-Xbootclasspath/a", which will force it to be used even in case of WebLogic
config entries like "prefer-web-inf-classes"
You need to consider some special aspect if you do this however:
You cannot make the class extend "AbstractLookup" or implement "StrLookup"
because this would create a class loader mess up (something like
"java.lang.LinkageError: loader constraint violation") in certain situations.
Therefore you what you will able to create is some "half-baked" class that
will fail to be loaded with a class cast exception looking like this in the log:
"JNDI lookup class is not available because this JRE does not support JNDI.
JNDI string lookups will not be available, continuing configuration. Ignoring
java.lang.ClassCastException: class
org.apache.logging.log4j.core.lookup.JndiLookup"
But the end justifies the means and since log4j is just complaining but not
failing on this exception I would see the above as a viable short term fix for
scenarios where you cannot touch the deployment build itself (I did validate
the same on a local Tomcat).
Of course in the longer run the remediation should be upgrading to a newer
version, re-build, re-test and redeploy ones whole application.
It would be great to get your thoughts on this, particularly if I have missed
anything substantial.
> JNDI lookups in layout (not message patterns) enabled in Log4j2 < 2.16.0
> ------------------------------------------------------------------------
>
> Key: LOG4J2-3221
> URL: https://issues.apache.org/jira/browse/LOG4J2-3221
> Project: Log4j 2
> Issue Type: Bug
> Reporter: Lucy Menon
> Priority: Major
> Fix For: 2.16.0
>
>
> The mitigation advice for CVE-2021-4428 suggests that for Log4j > 2.10.0 and
> < 2.15.0, the vulnerability can be avoided by setting
> -{{{}Dlog4j2.formatMsgNoLookups=true{}}} or upgrading to 2.15.0. However,
> many users may not be aware that even in this case, lookups used in layouts
> to provide specific pieces of context information will still recursively
> resolve, possibly triggering JNDI lookups. In order to avoid
> attacker-controlled JNDI lookups, users must also either:
> * Ensure that no such lookups resolve to attacker-provided data
> * Ensure that the the JndiLookup class is not loaded
> * Upgrade to log4j2 2.16.0 (untested)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
