hohn/codeql
1
0
Fork 0
mirror of https://github.com/github/codeql.git synced 2026-04-29 10:45:15 +02:00
Code Issues Packages Projects Releases Wiki Activity

Apply suggestions from code review

Browse Source 
Co-authored-by: Bas van Schaik <5082246+sj@users.noreply.github.com>
Co-authored-by: Marcono1234 <Marcono1234@users.noreply.github.com>
This commit is contained in:
Tony Torralba
2021-12-13 19:39:52 +01:00
committed by GitHub
parent 43a10457dd
commit d2dc19900f
2 changed files with 9 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
java/ql/src/experimental/Security/CWE/CWE-020/Log4jJndiInjection.qhelp
View File

@@ -5,19 +5,19 @@
<overview>
<p>
Log4j versions prior to 2.15.0 are subject to a remote code execution vulnerability via the ldap JNDI parser.
This query flags up situations in which untrusted user data is included in Log4j messages. If an application uses a Log4j version prior to 2.15.0, using untrusted user data in log messages will make an application vulnerable to remote code execution through Log4j's LDAP JNDI parser (CVE-2021-44228).
</p>
<p>
As per Apache's Log4j security guide: Apache Log4j2 &lt;=2.14.1 JNDI features used in configuration, log messages, and parameters
do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or
log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.
From log4j 2.15.0, this behavior has been disabled by default.
From Log4j 2.15.0, this behavior has been disabled by default. Note that this query will not try to determine which version of Log4j is used.
</p>
</overview>
<recommendation>
<p>
This issue was remediated in Log4J v2.15.0. The Apache Logging Services team provides the following mitigation advice:
This issue was remediated in Log4j v2.15.0. The Apache Logging Services team provides the following mitigation advice:
</p>
<p>
In previous releases (>=2.10) this behavior can be mitigated by setting system property "log4j2.formatMsgNoLookups" to “true”
@@ -25,14 +25,14 @@ or by removing the JndiLookup class from the classpath (example: zip -q -d log4j
Java 8u121 protects against RCE by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".
</p>
<p>
You can manually check for use of affected versions of Log4J by searching your project repository for Log4J use, which is often in a pom.xml file.
You can manually check for use of affected versions of Log4j by searching your project repository for Log4j use, which is often in a pom.xml file.
</p>
<p>
Where possible, upgrade to Log4J version 2.15.0. If you are using Log4J v1 there is a migration guide available.
</p>
<p>
Please note that Log4J v1 is End Of Life (EOL) and will not receive patches for this issue. Log4J v1 is also vulnerable to other RCE vectors and we
recommend you migrate to Log4J 2.15.0 where possible.
Please note that Log4j v1 is End Of Life (EOL) and will not receive patches for this issue. Log4j v1 is also vulnerable to other RCE vectors and we
recommend you migrate to Log4j 2.15.0 where possible.
</p>
<p>
If upgrading is not possible, then ensure the -Dlog4j2.formatMsgNoLookups=true system property is set on both client- and server-side components.

6
java/ql/src/experimental/Security/CWE/CWE-020/Log4jJndiInjection.ql
View File

@@ -1,11 +1,11 @@
/**
* @name Log4j JNDI Injection
* @name Log4j log injection and LDAP JNDI injection
* @description Building Log4j log entries from user-controlled data may allow
* attackers to inject malicious code through JNDI lookups.
* @kind path-problem
* @problem.severity error
* @precision high
* @id java/log4j-jndi-injection
* @id java/log4j-injection
* @tags security
* external/cwe/cwe-020
* external/cwe/cwe-074
@@ -168,7 +168,7 @@ private class LoggingSinkModels extends SinkModelCsv {
"org.apache.logging.log4j;LogBuilder;true;log;(String,Object,Object,Object,Object,Object,Object,Object,Object);;Argument[0..8];logging",
"org.apache.logging.log4j;LogBuilder;true;log;(String,Object,Object,Object,Object,Object,Object,Object,Object,Object);;Argument[0..9];logging",
"org.apache.logging.log4j;LogBuilder;true;log;(String,Object,Object,Object,Object,Object,Object,Object,Object,Object,Object);;Argument[0..10];logging",
"org.apache.logging.log4j;LogBuilder;true;log;(String,Supplier);;Argument[0..1];logging",
"org.apache.logging.log4j;LogBuilder;true;log;(String,Supplier[]);;Argument[0..1];logging",
"org.apache.logging.log4j;LogBuilder;true;log;(Supplier);;Argument[0];logging"
]
}