Hi Jinwoo,
Thanks for your thorough analysis on my feedback. After reviewing your
analysis, I'd like to propose an alternative approach that leverages Geode's
existing security infrastructure rather than creating parallel filtering
systems.
## The Core Issue
The vulnerability exists because session management bypasses Geode's robust
ClassLoader resolution and uses manual `ClassLoaderObjectInputStream`
reconstruction:
```java
// Current vulnerable code in GemfireHttpSession.getAttribute() (lines 147-149)
ObjectInputStream ois = new ClassLoaderObjectInputStream(
new ByteArrayInputStream(baos.toByteArray()), loader);
tmpObj = ois.readObject(); // No filtering applied!
```
## Proposed Solution: Thread Context ClassLoader
Instead of creating new filtering infrastructure, we can leverage Geode's
existing `ClassPathLoader` delegation chain:
```java
// Secure alternative using existing infrastructure in GemfireHttpSession.java
ClassLoader originalTCCL = Thread.currentThread().getContextClassLoader();
try {
Thread.currentThread().setContextClassLoader(webAppClassLoader);
// Uses ALL existing Geode filters + secure ClassLoader resolution
// BlobHelper → DataSerializer → InternalDataSerializer → ClassPathLoader
return BlobHelper.deserializeBlob(serializedData);
} finally {
Thread.currentThread().setContextClassLoader(originalTCCL);
}
```
## Why This Works
Geode's `ClassPathLoader.java` already follows this delegation order:
1. Custom loaders
2. **Thread context ClassLoader** ← We set this to web app ClassLoader
3. Geode's ClassLoader
4. System ClassLoader
This approach:
- ✅ **Closes the vulnerability** using existing filtered deserialization
- ✅ **Maintains ClassLoader isolation** for web applications
- ✅ **Leverages proven infrastructure** instead of duplicating it
- ✅ **Provides consistent security model** across all Geode components
## Benefits Over Dual Filtering
- **Simpler architecture** - single security model
- **Better maintainability** - no parallel infrastructure
- **Future-proof** - automatically benefits from Geode security enhancements
- **Lower risk** - uses battle-tested deserialization paths
## Evidence This Works
The existing test `BlobHelperWithThreadContextClassLoaderTest.java` proves that
`BlobHelper.deserializeBlob()` already handles ClassLoader mismatches correctly
using Geode's `ClassPathLoader` mechanism.
I believe this approach addresses both the immediate security concern and
long-term architectural consistency. Would you be open to exploring this
direction?
Best regards,
Sai
On 2025/12/05 17:04:54 Jinwoo Hwang via dev wrote:
> Hi Sai,
>
> Thank you very much for your careful review and for raising these important
> architectural considerations. I appreciate your insights and the
> thoughtfulness you bring to ensuring Apache Geode’s security.
>
> I’d like to provide some context on why I took the dual-filter approach
> intentionally and how it aligns with established security practices.
> Comprehensive details along with the architectural diagram are available
> here: https://github.com/apache/geode/pull/7941#issuecomment-3617666432
>
> Rationale for Separate Filters
>
> The two filters address fundamentally different trust boundaries and threat
> models:
> -HTTP/Session (SafeDeserializationFilter, 80 classes, always active):
> Protects against external attackers, session hijacking, and unsafe user input.
> -Cluster/Internal (validate-serializable-objects, 485 classes, optional):
> Protects internal replication, peer-to-peer communication, and cluster
> integrity.
>
> This separation reflects standard defense-in-depth architecture (Spring
> Security, AWS, Kubernetes, Hazelcast, Microsoft SDL). Each boundary requires
> independent policies; merging them could weaken security.
>
> Addressing Your Discussion Points
>
> -Extending existing infrastructure: Not ideal. Cluster filters protect
> internal data, while SafeDeserializationFilter targets the HTTP boundary.
> -Unified configuration: Unification would blur security boundaries; these
> configurations are intended to be managed by different roles.
> -Migration path: PR-7941 includes 80 common JDK classes in the allowlist.
> Existing session data works without migration.
> -Threat models: The filters address distinct threats, external HTTP attackers
> vs compromised cluster members with context-specific policies.
>
> PR-7941 introduces this new HTTP boundary layer to close the critical
> vulnerability while keeping cluster-level defenses optional.
>
> I hope this provides clarity on the architectural reasoning and why
> maintaining two separate filters is necessary. I value your guidance and
> would be happy to discuss this further if helpful.
>
>
> Best regards,
>
> Jinwoo Hwang (he/him/his)
>
>
>
> SAS® Research and Development
>
> http://JinwooHwang.com<http://jinwoohwang.com/>
>
>
>
> From: Sai Boorlagadda <[email protected]>
> Date: Thursday, December 4, 2025 at 12:18 PM
> To: [email protected] <[email protected]>
> Subject: PR 7941 - introduces session deserialization discussion
>
> EXTERNAL
>
> Hi Geode Community,
>
> I've been reviewing PR-7941 which addresses critical deserialization
> vulnerabilities in session management. The implementation is solid and
> well-engineered, but I'd like to step back and discuss the architectural
> approach before we proceed.
>
> ## Current PR Approach
> PR-7941 introduces SafeDeserializationFilter - a new, session-specific
> filtering system that operates independently of Geode's existing
> serialization infrastructure.
>
> ## Architectural Concern
>
> This creates a dual filtering system:
> 1. Existing Geode filters (GlobalSerialFilterConfiguration,
> ReflectiveFacadeStreamSerialFilter) for region data
>
> 2. New SafeDeserializationFilter for session attributes
> Since sessions are stored in Geode regions, session data
> potentially goes through BOTH filtering systems, creating:
> - Configuration complexity (two separate whitelist systems)
> - Operational burden (maintaining dual security policies)
> - User confusion (different config for sessions vs regions)
> - Potential security gaps (inconsistent policies)
>
> ## Discussion Points
> 1. Should we extend existing Geode serialization infrastructure instead?
> 2. How do we provide unified configuration for users?
> 3. What's the migration path for existing session deployments?
> 4. How do we handle the different threat models (web apps vs distributed
> cache)?
>
> ## Proposed Alternatives
> - Extend SerializableObjectConfig with session-specific options
> - Integrate with existing SanctionedSerializablesService
> - Provide session-specific sanctioned-serializables files
> - Unified validate-session-serializable-objects configuration
>
> I believe the security problem is real and urgent, but want to ensure
> we choose the right architectural approach for the long term.
>
> Thoughts?
>
> Best regards,
> Sai Boorlagadda
>
