[jira] [Commented] (LOG4J2-3371) Log Injection Vulnerability exists in Log4j2 default configuration
[
https://issues.apache.org/jira/browse/LOG4J2-3371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17490694#comment-17490694
]
Ralph Goers commented on LOG4J2-3371:
-
[~ggregory] We certainly could escape all control characters. That is exactly
what Json Template Layout does. However, that would require an enhancement to
the enc pattern converter.
[~4ra1n] Although as a group we haven't discussed it I suspect we would not
change the default behavior of the PatternLayout. That would be very disruptive
to users.
> 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)
[jira] [Commented] (LOG4J2-3371) Log Injection Vulnerability exists in Log4j2 default configuration
[
https://issues.apache.org/jira/browse/LOG4J2-3371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17490551#comment-17490551
]
4ra1n commented on LOG4J2-3371:
---
In fact, for this problem, there are corresponding reasons for publishing or
not publishing CVE
If you choose to publish, the reason is to inform all projects using log4j
components of possible dangers through the CVE, and recommend them to upgrade
to the latest version. CVE of spring framework may be more for this purpose. I
didn't find direct log injection in spring core module. Instead, I found
possible injection points in other spring components using spring core module.
However, spring does not publish CVE in the components with log injection
directly, but in the spring core framework.
If you choose not to publish, the reason is that the vulnerability cannot be
triggered directly in log4j, that is, it is not a direct vulnerability of
log4j, but a weakness.
As for how to do it, we can have more discussion. If you fix the default
layout, a security report should be issued to alert projects using log4j
components, whether CVE exists or not.
> 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)
[jira] [Commented] (LOG4J2-3371) Log Injection Vulnerability exists in Log4j2 default configuration
[
https://issues.apache.org/jira/browse/LOG4J2-3371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17490479#comment-17490479
]
Gary D. Gregory commented on LOG4J2-3371:
-
If we were to allow for stripping out control characters like CR and LF (what
about tabs, NUL, DEL?), we'd certainly want to point out the consequence of
this feature for performance and garbage generation.
> 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)
[jira] [Commented] (LOG4J2-3371) Log Injection Vulnerability exists in Log4j2 default configuration
[
https://issues.apache.org/jira/browse/LOG4J2-3371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17490449#comment-17490449
]
Ralph Goers commented on LOG4J2-3371:
-
[~mattsicker] The fix for the PatternLayout requires more discussion. The %n
converter inserts a newline into the rendered message. Presumably you would
never want to escape that. However, %m contains the message being logged and
presumably you would always want to escape that. But what about %X? But I can
already do:
{code:java}
%enc{%X %m}{CRLF}%n
{code}
So do we really need to do any more than call that out as a best practice?
> 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)
[jira] [Commented] (LOG4J2-3371) Log Injection Vulnerability exists in Log4j2 default configuration
[
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)
[jira] [Commented] (LOG4J2-3371) Log Injection Vulnerability exists in Log4j2 default configuration
[
https://issues.apache.org/jira/browse/LOG4J2-3371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17490041#comment-17490041
]
4ra1n commented on LOG4J2-3371:
---
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)
[jira] [Commented] (LOG4J2-3371) Log Injection Vulnerability exists in Log4j2 default configuration
[
https://issues.apache.org/jira/browse/LOG4J2-3371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17490027#comment-17490027
]
Ralph Goers commented on LOG4J2-3371:
-
I personally do not consider this to be worthy of a CVE. I do consider it a
worthy enhancement request.
> 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)
[jira] [Commented] (LOG4J2-3371) Log Injection Vulnerability exists in Log4j2 default configuration
[
https://issues.apache.org/jira/browse/LOG4J2-3371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489986#comment-17489986
]
4ra1n commented on LOG4J2-3371:
---
At your convenience, would you please let me know what you think of this?
Recently, I found some similar problems in auditing other projects which using
log4j.
For example, in Apache Shiro, Shiro PMC suggested that I report the problem to
log4j.
As a well-known java project at the same level as the spring framework, it may
be a good way to refer to the solution of the spring framework.
I haven't received a reply for many days.
Do you think this is a low-risk security vulnerability? Or do you think it's
not a security issue?
Will further actions be taken, such as patch release and CVE?
> 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)
[jira] [Commented] (LOG4J2-3371) Log Injection Vulnerability exists in Log4j2 default configuration
[
https://issues.apache.org/jira/browse/LOG4J2-3371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17484040#comment-17484040
]
4ra1n commented on LOG4J2-3371:
---
Thank you for your reply. Layouts using JsonTemplateLayout and GelfLayout do
not have problems. However, the actual project does not necessarily use the
above two layouts.
For example, when configuring log4j2, many programmers will use some layout
configurations commonly used on the Internet. I tested some articles and blogs
and found that there is an injection problem. Or in some simple projects, the
default layout is directly used without configuration.
As a widely used standard library, dealing with any possible situation may be a
better solution, such as dealing with log injection in the default layout or
filtering some of its input
> 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 Apache Shiro.
> 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)
[jira] [Commented] (LOG4J2-3371) Log Injection Vulnerability exists in Log4j2 default configuration
[
https://issues.apache.org/jira/browse/LOG4J2-3371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17483874#comment-17483874
]
Ralph Goers commented on LOG4J2-3371:
-
This is very dependent on the layout you use. If you use JsonTemplateLayout
this problem does not exist as the enter message is captured in a message
element in the JSON. JsonTemplateLayout also "escapes" the control characters
so that their string representations as left in the string. This means that
when the JSON is passed to Kibana it sees the newline strings and formats them
properly in its UI.
I know that filebeat, fluentd, and fluentbit all have problems with newlines in
the logs. That can be handled by using Gelf via the GelfLayout or again JSON
created by JsonTemplateLayout.
So this really boils down to the possibility of adding an option to
PatternLayout to allow control character escaping using the same logic
JsonTemplateLayout does.
> 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
>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 Apache Shiro.
> 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)
