SunWeb3Sec opened a new pull request, #4098:
URL: https://github.com/apache/logging-log4j2/pull/4098
# Harden `ObjectArrayMessage.readObject()` with
`SerializationUtil.assertFiltered()`
## Summary
Adds a single `SerializationUtil.assertFiltered(in)` call at the top of
`ObjectArrayMessage.readObject()`, bringing it in line with the defensive
pattern already used by `ObjectMessage` and `ParameterizedMessage`.
## Change
`log4j-api/.../message/ObjectArrayMessage.java`
**Before**
```java
private void readObject(final ObjectInputStream in) throws IOException,
ClassNotFoundException {
in.defaultReadObject();
array = (Object[]) in.readObject();
}
```
**After**
```java
private void readObject(final ObjectInputStream in) throws IOException,
ClassNotFoundException {
SerializationUtil.assertFiltered(in);
in.defaultReadObject();
array = (Object[]) in.readObject();
}
```
Plus the corresponding `import
org.apache.logging.log4j.util.internal.SerializationUtil;`.
### What this PR deliberately does **not** do
- Does **not** change the serialized wire format — `ObjectArrayMessage`
instances produced by older versions still deserialize into a patched version,
and vice versa.
- Does **not** touch `LocalizedMessage` or `FormattedMessage`. They have
similar gaps, but the Log4j security team scoped this request to
`ObjectArrayMessage` only. Happy to submit follow-up PRs for those if desired.
- Does **not** modify existing tests
(`LocalizedMessageTest#testSerialization*`,
`FormattedMessageTest#testSerialization`) that use plain `ObjectInputStream`,
because those classes are untouched.
## Tests
Added a minimal round-trip test
(`ObjectArrayMessageTest#testSerializableRoundTripThroughFilteredStream`) that
serializes and deserializes through `SerialUtil`, which uses
`FilteredObjectInputStream` on Java 8 — verifying the new `assertFiltered()`
call accepts filtered streams.
## Behavioral note
On Java 8, deserializing an `ObjectArrayMessage` through a plain
`ObjectInputStream` (no JEP 290 filter) now throws `IllegalArgumentException`
instead of silently proceeding. This matches the existing behavior of
`ObjectMessage` and `ParameterizedMessage`. Callers that relied on unfiltered
deserialization of `ObjectArrayMessage` should wrap their streams in
`FilteredObjectInputStream`, matching the project's guidance for the sibling
message types.
On Java 9+, the behavior is unchanged — `assertFiltered()` is a no-op when a
JVM-level `ObjectInputFilter` is active, and a warning otherwise.
## Checklist
- [x] Single class changed (`ObjectArrayMessage`)
- [x] No wire format change
- [x] No new public API
- [x] No new dependencies
- [x] Unit test added
- [x] Changelog entry:
`src/changelog/.2.x.x/harden_message_deserialization.xml` (type `changed`)
## References
- Private discussion with the Log4j security team (HackerOne report, closed
as Informative — not a vulnerability; code-quality improvement welcomed).
- Hardened siblings for reference:
- `ObjectMessage#readObject`
- `ParameterizedMessage#readObject`
Thanks to the Log4j security team for the clear triage.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
