[
https://issues.apache.org/jira/browse/LOG4J2-3214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17458341#comment-17458341
]
Remko Popma commented on LOG4J2-3214:
-------------------------------------
[~AlexanderYastrebov] thank you for the feedback!
{quote}
> For releases >=2.0-beta9 and <2.7, remove the {{JndiLookup}}
I think the version range should include all versions, i.e. right boundary
should be the latest affected version. If users go for patching the library
they might want to patch all the versions instead of applying different fixes
for different versions
{quote}
The reason we single out this version range 2.0-beta9 to <2.7 is because for
this version range, modifying the log4j-core JAR is the *only* mitigation
mechanism available. I will update the text to emphasize this.
[~vy] It looks like with even only 3 people we already have very different
ideas of what the "preferred" mitigation mechanism is. This likely differs a
lot per environment. I propose we do not attempt to create a hierarchy of
preference, and just make it a simple bullet point list instead, where any of
the options is a valid mechanism.
One argument for ordering the mitigation mechanisms as below is that this is
the conventional order for any customization, but I am open to switching 2 and
3...
* latest version (no config needed)
* config
* system prop/environment var
* modify the JAR
I will change the wording to reflect the above.
> update security page text for CVE-2021-44228
> --------------------------------------------
>
> Key: LOG4J2-3214
> URL: https://issues.apache.org/jira/browse/LOG4J2-3214
> Project: Log4j 2
> Issue Type: Documentation
> Affects Versions: 2.15.0
> Reporter: Remko Popma
> Priority: Major
> Fix For: 2.16.0
>
>
> I propose to update the text for the mitigation section of CVE-2021-44228 on
> [https://logging.apache.org/log4j/2.x/security.html]
> Changes: add Log4j 1.x section, and format the Log4j 2.x section as a bullet
> point list for improved readability.
> ----
> {*}Log4j 1.x mitigation{*}: Audit your logging configuration to ensure it has
> no {{JMSAppender}} configured. Log4j 1.x configurations without JMSAppender
> are not impacted by this vulnerability.
> {*}Log4j 2.x mitigation{*}: Implement one of the below listed mitigation
> techniques, ordered from the most recommended approach to the least.
> # Upgrade to a version >=2.15.0 or later
> # For releases >=2.10,
> ** set system property {{log4j2.formatMsgNoLookups}} to {{true}} (see
> [details|https://logging.apache.org/log4j/2.x/manual/configuration.html#SystemProperties])
> ** or set environment variable {{LOG4J_FORMAT_MSG_NO_LOOKUPS}} to {{true}}
> (see
> [details|https://logging.apache.org/log4j/2.x/manual/configuration.html#SystemProperties]).
> # For releases >=2.7 and <=2.14.1, modify your logging configuration to
> disable message lookups:
> ** use {{{}%m{nolookups{}}}} instead of just {{%m}}
> ** use {{{}%msg{nolookups{}}}} instead of just {{%msg}}
> ** use {{{}%message{nolookups{}}}} instead of just {{%message}}
> # For releases >=2.0-beta9 and <2.7, remove the {{JndiLookup}} class from
> the classpath: {{zip \-q \-d log4j-core-*.jar
> org/apache/logging/log4j/core/lookup/JndiLookup.class}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
