[jira] [Commented] (LOG4J2-3371) Log Injection Vulnerability exists in Log4j2 default configuration

["Ralph Goers (Jira)" <ji...@apache.org>]

    [ 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)