[ https://issues.apache.org/jira/browse/LOG4J2-3221 ]
4ra1n deleted comment on LOG4J2-3221:
-------------------------------
was (Author: JIRAUSER281614):
I reported this problem to the logging PMC last week. Although I didn't propose
threadcontext, I also explained the trigger method of denial of service
vulnerability.I hope my name can also be added to CVE's credit
I sent a vulnerability report to
[[email protected]|mailto:[email protected]] on December 10
and received a reply and thanks from *Ralgh Goers* five hours later.
*[CVE-2021-45046|https://github.com/advisories/GHSA-7rjr-3q55-vv33]* seems to
have been proposed two days ago. It seems that I am ahead.
I just hope my name: 4ra1n can join credit of {{CVE-2021-45046}} on the page
{{https://logging.apache.org/log4j/2.x/security.htm}}
I hope you can remember to add my name after your current work. I will be very
grateful
> 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)
