diff --git a/ldap/src/main/java/de/seemoo/netsec/AttackInterceptor.java b/ldap/src/main/java/de/seemoo/netsec/AttackInterceptor.java index 52398e909e2fb89e09a94be7516b463ce292c0cb..fae77efbe83440fc65090a74b014fabe61d65c71 100644 --- a/ldap/src/main/java/de/seemoo/netsec/AttackInterceptor.java +++ b/ldap/src/main/java/de/seemoo/netsec/AttackInterceptor.java @@ -44,14 +44,16 @@ public class AttackInterceptor extends InMemoryOperationInterceptor { // Another approach would be to exploit (de-)serialization of objects which is also supported by LDAP, // but for this the system property 'com.sun.jndi.ldap.object.trustURLCodebase' must // have been set to 'true' for almost all Java versions. + // You can read more about it on https://www.innoq.com/en/articles/2022/04/java-jndi/. + // However, the approach can be used in combination with certain classes of libraries for RCE attacks. + // Those classes are also called gadgets, read more about it on: https://github.com/mbechler/marshalsec. - // Other approach: https://www.innoq.com/en/articles/2022/04/java-jndi/ - - // With this approach, it's not required to set the property for Java version <= 8u191. + // With the factory approach, it's not required to set the property for Java version <= 8u191. // https://news.ycombinator.com/item?id=29505027 // https://www.lunasec.io/docs/blog/log4j-zero-day/ // We've confirmed this with JDK & JRE 1.8.0u111 available at // https://www.oracle.com/de/java/technologies/javase/javase8-archive-downloads.html + // We suppose the problem is caused by CVE 2018-3149: https://bugzilla.redhat.com/show_bug.cgi?id=1639834. try { // Sends the newly generated malicious entry back to the requester