[
https://issues.apache.org/jira/browse/LOG4J2-3371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17490041#comment-17490041
]
4ra1n edited comment on LOG4J2-3371 at 2/10/22, 8:40 AM:
---------------------------------------------------------
Yes, for example, if other projects using log4j have log injection in specific
classes and methods, they should apply for CVE.
However, log4j itself does not have vulnerability, so applying for CVE is not
necessarily the right way.However, you can also consider applying for CVE to
inform other projects
I suggest that log4j release a patch and then announce a security report to
remind all projects using log4j to upgrade to avoid possible log injection
vulnerabilities.
Whether CVE should be published for this purpose can be discussed with logging
PMC
was (Author: JIRAUSER281614):
Yes, for example, if other projects using log4j have log injection in specific
classes and methods, they should apply for CVE.
However, log4j itself does not have loopholes, so applying for CVE is not
necessarily the right way.
I suggest that log4j release a patch and then announce a security report to
remind all projects using log4j to upgrade to avoid possible log injection
vulnerabilities.
Whether CVE should be published for this purpose can be discussed with logging
PMC
> Log Injection Vulnerability exists in Log4j2 default configuration
> ------------------------------------------------------------------
>
> Key: LOG4J2-3371
> URL: https://issues.apache.org/jira/browse/LOG4J2-3371
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.17.1
> Reporter: 4ra1n
> Assignee: Ralph Goers
> Priority: Major
>
> For information about log injection, refer to OWASP:
> [https://owasp.org/www-community/attacks/Log_Injection]
>
> Some time ago, the spring framework revealed two CVE vulnerabilities related
> to log injection: CVE-2021-22096 and CVE-2021-22060:
> [https://tanzu.vmware.com/security/cve-2021-22096]
> [https://tanzu.vmware.com/security/cve-2021-22060]
> Their fix is to filter the log content, such as not allowing line seprators
>
> Some time ago, I found a log injection vulnerability in other Apache project,
> which use log4j2. Although the vulnerability is effective and can be
> triggered, they think I should report the problem to Apahce Log4j and prevent
> such log injection vulnerability under the default configuration
>
> code(under the default configuration)
> {code:java}
> public static void main(String[] args) {
> Logger logger = LogManager.getLogger(Main.class);
> logger.info("test\n00:00:00.000 [main] ERROR com.text.Class -
> xxx\nxxx");
> } {code}
>
> output(under the default configuration)
> {code:java}
> 09:47:34.190 [main] INFO com.example.Main - test
> 00:00:00.000 [main] ERROR com.text.Class - xxx
> xxx {code}
> On the exploitation of vulnerabilities: for example, add some confused logs,
> such as forged IP, forged classes, forged error reports and exceptions, which
> brings trouble to the operation and maintenance personnel and auditors.
> Further, if there is an internal log analysis platform, and the xxx is
> wrapped by the script tag, that is, JavaScript code, the platform reading the
> log may have XSS vulnerabilities.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
