You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@logging.apache.org by "ppkarwasz (via GitHub)" <gi...@apache.org> on 2026/08/31 20:55:25 UTC

[PR] Reject dynamic proxies in `FilteredObjectInputStream` [logging-log4j2]

ppkarwasz opened a new pull request, #4269:
URL: https://github.com/apache/logging-log4j2/pull/4269

   > [!IMPORTANT]
   > This PR is part of the deserialization hardening work tracked in #4168. The Logging Services PMC does **not** use nor recommend Java serialization/deserialization, and [our security FAQ](https://logging.apache.org/security/faq.html#deserialization) has long documented this position. This work is submitted solely to reduce the false-positive "vulnerability" reports that keep being filed regardless of that FAQ. Its utility for end users is close to zero.
   
   On Java 8, `FilteredObjectInputStream` is the only deserialization protection available, but dynamic proxy class descriptors are resolved through `ObjectInputStream#resolveProxyClass`, not `resolveClass`, so they bypassed the allowlist entirely. A stream could thus instantiate a proxy of arbitrary interfaces on the Java 8 code path.
   
   On Java 9 and later, the JEP 290 filter already rejects proxies, because their synthetic class names (`com.sun.proxy.$ProxyN`, `jdk.proxy1.$ProxyN`, …) never match the allowlist. This PR aligns the Java 8 path by overriding `resolveProxyClass` to reject proxies outright — no supported Log4j serialized form contains one.
   
   The rejection also applies when extra allowed classes are supplied to the constructor; proxies are never legitimate in a Log4j stream, so there is no opt-out.
   


-- 
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: [PR] Reject dynamic proxies in `FilteredObjectInputStream` [logging-log4j2]

Posted by "ramanathan1504 (via GitHub)" <gi...@apache.org>.
ramanathan1504 commented on PR #4269:
URL: https://github.com/apache/logging-log4j2/pull/4269#issuecomment-5574010929

   @ppkarwasz 
    I removed the `resolveProxyClass` override and ran the test. Both proxy tests fail with "nothing was thrown". So they test the new override, they do not trip over the handler
     class.                                                                                                                                                                        
                                                                                                                                                                                   
     One correction for the Javadoc, left inline.


-- 
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: [PR] Reject dynamic proxies in `FilteredObjectInputStream` [logging-log4j2]

Posted by "ppkarwasz (via GitHub)" <gi...@apache.org>.
ppkarwasz commented on code in PR #4269:
URL: https://github.com/apache/logging-log4j2/pull/4269#discussion_r4135829564


##########
log4j-api/src/main/java/org/apache/logging/log4j/util/FilteredObjectInputStream.java:
##########
@@ -71,6 +71,20 @@ protected Class<?> resolveClass(final ObjectStreamClass desc) throws IOException
         return super.resolveClass(desc);
     }
 
+    /**
+     * Unconditionally rejects dynamic proxy classes.
+     * <p>
+     *     Proxy class descriptors do not pass through {@link #resolveClass(ObjectStreamClass)}, so they would
+     *     otherwise bypass the allowlist entirely. No supported Log4j serialized form contains a dynamic proxy, and
+     *     the JEP 290 filter used on Java 9 and later rejects proxy classes as well, since their synthetic class names
+     *     never match the allowlist.

Review Comment:
   Thanks for the review. Instead of correcting this sentence, I removed it: `DefaultObjectInputFilter` is going away in #4365, so the Javadoc now only states why proxies are rejected.



-- 
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: [PR] Reject dynamic proxies in `FilteredObjectInputStream` [logging-log4j2]

Posted by "ramanathan1504 (via GitHub)" <gi...@apache.org>.
ramanathan1504 merged PR #4269:
URL: https://github.com/apache/logging-log4j2/pull/4269


-- 
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: [PR] Reject dynamic proxies in `FilteredObjectInputStream` [logging-log4j2]

Posted by "ramanathan1504 (via GitHub)" <gi...@apache.org>.
ramanathan1504 commented on code in PR #4269:
URL: https://github.com/apache/logging-log4j2/pull/4269#discussion_r3951337223


##########
log4j-api/src/main/java/org/apache/logging/log4j/util/FilteredObjectInputStream.java:
##########
@@ -71,6 +71,20 @@ protected Class<?> resolveClass(final ObjectStreamClass desc) throws IOException
         return super.resolveClass(desc);
     }
 
+    /**
+     * Unconditionally rejects dynamic proxy classes.
+     * <p>
+     *     Proxy class descriptors do not pass through {@link #resolveClass(ObjectStreamClass)}, so they would
+     *     otherwise bypass the allowlist entirely. No supported Log4j serialized form contains a dynamic proxy, and
+     *     the JEP 290 filter used on Java 9 and later rejects proxy classes as well, since their synthetic class names
+     *     never match the allowlist.

Review Comment:
   This is true only with the default filter. `DefaultObjectInputFilter.checkInput` asks the process-wide `jdk.serialFilter` first and returns its answer. So a permissive one still lets a proxy through on Java 9+.
   
   ```suggestion
        *     {@code DefaultObjectInputFilter} rejects proxy classes on Java 9 and later, since their synthetic class
        *     names never match the allowlist, unless a process-wide serial filter allows them first.
   ```



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