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

Reply via email to