[
https://issues.apache.org/jira/browse/LOG4J2-3371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17490415#comment-17490415
]
Matt Sicker commented on LOG4J2-3371:
-------------------------------------
I doubt the PMC would approve of publishing a CVE for this. Changing the
default behavior of PatternLayout in a 2.x release would be fairly surprising
(though we have changed default behavior in the past in response to other
security issues). I'd kind of expect that most users would notice this as a
potential problem the minute they start parsing their log files line by line
and seeing stack traces split across multiple log messages as a result. That
naturally leads to looking at more structured output formats. I'd hope that
users typically use PatternLayout for development purposes and not necessarily
as their only log file structure, but I can totally imagine many users sticking
with the defaults.
Anyways, I'd be in favor of changing the default behavior here, though as a
CVE, even using the most paranoid calculation, would be at worst a 5.3
([AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N|https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N&version=3.1]).
This vulnerability is more of a weakness (as in
[https://cwe.mitre.org/data/definitions/117.html]) and really only becomes a
CVE in an application setting where log injection is exploitable. If there were
some other way to publish this to security tools so that they'd more
intelligently flag applications that allow for log injection to be exploited,
that might work.
> 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)
