Hi Sai, I would like to understand one aspect of the TCCL approach.
Since serializable-object-filter is configured at the cluster level (in gemfire.properties), how would this handle scenarios where multiple applications share the same Geode cluster? This is a common pattern in enterprise deployments, microservices architectures, multi-team environments, or cloud-native applications using a shared caching tier. Example: If App A needs com.payment.** and App B needs com.ml.**, the cluster configuration would be: Both applications could now deserialize each other's classes. From a security perspective, this creates a concern: if App A is compromised, an attacker could inject malicious objects from App B's domain (e.g., com.ml.**), potentially escalating the attack across application boundaries. This appears to violate the Principle of Least Privilege. -Is there a mechanism for per-application security policies with the TCCL approach that I'm missing? -Would the recommendation be to use dedicated clusters per application? (This would solve the isolation problem but significantly increases operational overhead and infrastructure costs.) -How does this align with Geode's existing fine-grained access control (e.g., SecurityManager for region-level authorization)? It seems inconsistent to have granular data access control but shared deserialization policies. I appreciate your insight and the depth of your expertise. Best regards, Jinwoo Hwang (he/him/his) SAS® Research and Development http://JinwooHwang.com<http://jinwoohwang.com/> From: Jinwoo Hwang via dev <[email protected]> Date: Monday, December 8, 2025 at 2:20 PM To: [email protected] <[email protected]> Cc: Jinwoo Hwang <[email protected]> Subject: Re: PR 7941 - introduces session deserialization discussion EXTERNAL Hi Sai, I’m grateful that you took the time to review the architecture and design of this work. Your expertise and perspective on what best serves Apache Geode’s long-term security are invaluable. I have no desire to advance my own approach for its own sake, even though I’ve invested quite a bit of time in it. What matters most is ensuring that Apache Geode’s session management is secure and consistent with the project’s overall security architecture. I’m completely open to whichever direction the community believes is best, and if we decide to apply the “user-configured security to sessions” policy, I’m more than willing to set aside this implementation and support your architecture wholeheartedly. Thank you again for your guidance and for the time you’ve dedicated to this discussion. It’s truly a privilege to have the opportunity to learn from a veteran like you, with such deep expertise and experience. Best regards, Jinwoo Hwang (he/him/his) SAS® Research and Development https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect.checkpoint.com%2Fv2%2Fr01%2F___http%3A%2F%2FJinwooHwang.com___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86YWI3MWQ3MDA4ZTg5ZDZhMmFkOTA3YWU2MjgwMzBjOGI6Nzo0MjM5Ojg2ZTBjMjZkZDBmZTQ1YmZhMmU1Y2QwOTY4ZTMyMmJjOTZkOWQ1YzRiZDBmMDk4MjM1NWIyMzQ1YmQ0YzkzNGU6cDpUOk4&data=05%7C02%7CJinwoo.Hwang%40sas.com%7Ce592270eda4f4beab5d908de368ed82a%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008184338037741%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=z0O2cXufx9rUzU0uM51btatUUZT0UfJxoEkFH8lZQGo%3D&reserved=0<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect.checkpoint.com%2Fv2%2Fr01%2F___http%3A%2F%2Fjinwoohwang.com%2F___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86YWI3MWQ3MDA4ZTg5ZDZhMmFkOTA3YWU2MjgwMzBjOGI6NzpkMmYwOjg4ZjZkZGZhZjkyZDVhOTVhNTZiZjlkYzVjMGE1OTdmNjg1MmU2MDk3NjI5ZmMzMjMwYjcyOTNmNDJlODE1Nzk6cDpUOk4&data=05%7C02%7CJinwoo.Hwang%40sas.com%7Ce592270eda4f4beab5d908de368ed82a%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008184338050843%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=FZIaiE3XS%2Bb%2Fz%2BM97ETjMLJQTZ8PTrZd1CR5YIrTEz8%3D&reserved=0><https://protect.checkpoint.com/v2/r01/___http://JinwooHwang.com___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86YWI3MWQ3MDA4ZTg5ZDZhMmFkOTA3YWU2MjgwMzBjOGI6Nzo0MjM5Ojg2ZTBjMjZkZDBmZTQ1YmZhMmU1Y2QwOTY4ZTMyMmJjOTZkOWQ1YzRiZDBmMDk4MjM1NWIyMzQ1YmQ0YzkzNGU6cDpUOk4> From: Sai Boorlagadda <[email protected]> Date: Monday, December 8, 2025 at 11:08 AM To: [email protected] <[email protected]> Subject: Re: PR 7941 - introduces session deserialization discussion EXTERNAL Hi Jinwoo, Thank you for your analysis. I apologize for not being precise in my original explanation. TCCL would not automatically apply security filters. When I looked at the session mgmt code, it bypasses Geode's serialization infrastructure during reconstruction which if we fix to use existing infrastructure that applies whitelist-only filtering when `validate-serializable-objects=true` is configured. I believe when `validate-serializable-objects=false`, then by default its initialized as `serializationFilter = new NullStreamSerialFilter()` and provides no protection, but when set to `true` it should be initialized to SanctionedSerializablesFilterPattern, which should not allow any classes to deserialize (`!*`) by default unless user configures whitelisted classes using `serializable-object-filter`. So the TCCL approach would require users to configure their session classes in `serializable-object-filter`, which is actually aligns with Geode's security philosophy of requiring explicit user configuration for deserialization. Looking at earlier fixes CVE-2022-37021 (JMX over RMI Deserialization), we let user configure the protection rather than built-in security. Should session management follow Geode's consistent "user-configured security" pattern, or require a built-in security? ### **TCCL Approach:** - **User Configuration Required**: - `validate-serializable-objects=true` - `serializable-object-filter=com.enterprise.model.**,com.enterprise.dto.**` - **Breaking Change**: Sessions would reject unconfigured - **Unified Architecture**: Same filtering system across cache operations and sessions - **Security by Default**: No deserialization without explicit user configuration. If this doesnt solve what is required for the new security fix that is provided by PR-7941, I am good to go ahead with the approach proposed in the PR. Sai On 2025/12/05 22:46:31 Jinwoo Hwang via dev wrote: > Hi Sai, > > Thank you for taking the time to review this PR and propose an alternative > architectural approach. I genuinely appreciate your thoughtful consideration > of how this could integrate with Geode's existing infrastructure. > > I'd like to better understand the security coverage of your proposed Thread > Context ClassLoader approach. You mentioned two key benefits: > > "Closes the vulnerability immediately" > "Uses ALL existing Geode security filters" > > I want to make sure I understand this correctly. My current implementation > explicitly blocks: > > -26 specific gadget classes (InvokerTransformer, ChainedTransformer, > TemplatesImpl, ObjectFactory, MethodClosure, JndiRefForwardingDataSource, > etc.) > -10 dangerous package patterns (org.apache.commons.collections.functors., > org.springframework.beans.factory., java.rmi.*, etc.) > > Could you help me understand how your proposed approach would block these > same classes? Specifically: > > 1.Which existing Geode filter(s) block these gadget chains? > I traced through the code and found that serializationFilter defaults to > NullStreamSerialFilter (line 294 in InternalDataSerializer.java). Looking at > the implementation: > > // NullStreamSerialFilter.java > public class NullStreamSerialFilter implements StreamSerialFilter { > @Override > public void setFilterOn(ObjectInputStream objectInputStream) { > // Do nothing, this is the case where we don't filter. > } > } > This is explicitly documented as "Implementation of StreamSerialFilter that > does nothing" with the comment "Do nothing, this is the case where we don't > filter." So by default, no filtering is applied. > > 2.Does sanctioned-geode-core-serializables.txt contain gadget blocking > entries? > I examined this file (485 lines) and found it contains only Apache Geode > internal classes (exceptions, cache operations, admin/management, PDX > serialization). > This appears to be a whitelist of Geode-internal classes for cluster > operations, not a security blocklist. It contains 485 Geode classes but zero > gadget chain blocking entries. > > Regarding your statement that this "closes the vulnerability immediately" - I > want to understand the mechanism. The vulnerability exists because malicious > gadget chains (like InvokerTransformer) can be deserialized without any > validation. For the vulnerability to be closed: > > -These specific classes must be blocked during deserialization, OR > -An allowlist must reject classes not explicitly permitted > > Could you clarify which of these mechanisms the TCCL approach uses? From my > code analysis, I see that BlobHelper.deserializeBlob() calls through to > InternalDataSerializer which applies serializationFilter (currently > NullStreamSerialFilter by default). This appears to provide no blocking of > gadget chains. > > I may be misunderstanding how Geode's existing filter infrastructure works. > If there's existing gadget chain protection in Geode that I'm missing, I'd be > very grateful if you could point me to the specific code or configuration > that provides this protection. > > I've invested considerable effort creating 28 unit tests in this PR covering > gadget blocking, resource limits, and various configuration scenarios - all > demonstrating that SafeDeserializationFilter successfully blocks known attack > chains. Could you share examples or point me to existing tests that > demonstrate how TCCL prevents classes like InvokerTransformer from being > deserialized and executed? That would really help me understand the > protection mechanism you're describing. > > My goal is to understand whether the Thread Context ClassLoader approach > provides equivalent security coverage to the explicit > SafeDeserializationFilter, or if additional work would be needed to add > gadget chain protection to Geode's core infrastructure. > > Specific concern: If we adopt the TCCL approach without gadget blocking, an > attacker could still send a malicious InvokerTransformer object in a session > attribute. The TCCL would successfully load the class (improving > compatibility), but the gadget chain would execute, achieving RCE. Is there a > mechanism I'm missing that prevents this? > > I'm completely open to integrating with Geode's existing infrastructure if it > can provide the same security guarantees. I just want to make sure we don't > inadvertently leave the vulnerability open while we work on architectural > improvements. > > Thank you again for your guidance and expertise on this. > > > Best regards, > > Jinwoo Hwang (he/him/his) > > > > SAS® Research and Development > > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect.checkpoint.com%2Fv2%2Fr01%2F___http%3A%2F%2FJinwooHwang.com___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86ZjcxMDI5Yzk5YWY2OGNiZDYwMDJjYjNlOGJmNTQ0NDA6Nzo0NzFjOjUzNGU2N2RmOWI4M2QyY2I4MzQ0ZDBiOGI4OTgxYWYzMWU0ZTQyMjUyM2I5Mzc1NDRkMzZkMzI5MmQwYzg2NzA6cDpUOk4&data=05%7C02%7CJinwoo.Hwang%40sas.com%7Ce592270eda4f4beab5d908de368ed82a%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008184338059132%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=gEwEQklUyi88dD2LPrYQsTmh3Dk2XxtSE1viSk2qGRE%3D&reserved=0<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect.checkpoint.com%2Fv2%2Fr01%2F___http%3A%2F%2Fjinwoohwang.com%2F___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86ZjcxMDI5Yzk5YWY2OGNiZDYwMDJjYjNlOGJmNTQ0NDA6NzpmMTczOmEzNDU5MzVjYzRkZThjYTVjMTNkNGFmN2IyZjg2MDM4ODFkYjY5MzljMGNlZDZiMWFjNTE4M2M1NzFjZDQyYjM6cDpUOk4&data=05%7C02%7CJinwoo.Hwang%40sas.com%7Ce592270eda4f4beab5d908de368ed82a%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008184338067289%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=dTp1C%2Bfe7%2BXwGJqCjPPPvT85dpjC16zNat%2Bo%2FuIiPIc%3D&reserved=0><https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect.checkpoint.com%2Fv2%2Fr01%2F___http%3A%2F%2FJinwooHwang.com___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86ZjcxMDI5Yzk5YWY2OGNiZDYwMDJjYjNlOGJmNTQ0NDA6Nzo0NzFjOjUzNGU2N2RmOWI4M2QyY2I4MzQ0ZDBiOGI4OTgxYWYzMWU0ZTQyMjUyM2I5Mzc1NDRkMzZkMzI5MmQwYzg2NzA6cDpUOk4&data=05%7C02%7CJinwoo.Hwang%40sas.com%7Ce592270eda4f4beab5d908de368ed82a%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008184338075272%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=bln3SERbtNoL%2FYEFu0L%2FjLSxxu54WFTLxyVGx3jXuiE%3D&reserved=0><https://protect.checkpoint.com/v2/r01/___http://JinwooHwang.com___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86ZjcxMDI5Yzk5YWY2OGNiZDYwMDJjYjNlOGJmNTQ0NDA6Nzo0NzFjOjUzNGU2N2RmOWI4M2QyY2I4MzQ0ZDBiOGI4OTgxYWYzMWU0ZTQyMjUyM2I5Mzc1NDRkMzZkMzI5MmQwYzg2NzA6cDpUOk4> > > > > From: Sai Boorlagadda <[email protected]> > Date: Friday, December 5, 2025 at 1:59 PM > To: [email protected] <[email protected]> > Subject: Re: PR 7941 - introduces session deserialization discussion > > EXTERNAL > > 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://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect.checkpoint.com%2Fv2%2Fr01%2F___https%3A%2F%2Fnam02.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fgithub.com%252Fapache%252Fgeode%252Fpull%252F7941*23issuecomment-3617666432%26data%3D05%257C02%257CJinwoo.Hwang%2540sas.com%257C32961c14aeee46edf7a308de3430558c%257Cb1c14d5c362545b3a4309552373a0c2f%257C0%257C0%257C639005579398526167%257CUnknown%257CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%253D%253D%257C0%257C%257C%257C%26sdata%3D5yjPttOwctBkDkjKtXLMwCFNu72ffVyu8FV0xN%252Fp2K8%253D%26reserved%3D0___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86ZjcxMDI5Yzk5YWY2OGNiZDYwMDJjYjNlOGJmNTQ0NDA6NzoyY2Q5OjczYWE0ZTAzZTI1OGQzMjE2OGZkZDRiMjNhZTFhZGIyZTU1ZTE0MTU0NWNiNTEwMWJiOTIwMmRmMzVlYTRhNTk6cDpUOk4&data=05%7C02%7CJinwoo.Hwang%40sas.com%7Ce592270eda4f4beab5d908de368ed82a%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008184338082757%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=11G7ws3WPusr31Xa%2BGZHedCWmVTIzukDo7eMy4DrnKk%3D&reserved=0<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect.checkpoint.com%2Fv2%2Fr01%2F___https%3A%2F%2Fnam02.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fgithub.com%252Fapache%252Fgeode%252Fpull%252F7941*23issuecomment-3617666432%26data%3D05%257C02%257CJinwoo.Hwang%2540sas.com%257C2df9b030540e46d8eae008de3673f146%257Cb1c14d5c362545b3a4309552373a0c2f%257C0%257C0%257C639008068856127299%257CUnknown%257CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%253D%253D%257C0%257C%257C%257C%26sdata%3DaS%252FupxvOYg4uHwwoQOlWqorWjMcjqaaUBeZbUSmhqhU%253D%26reserved%3D0___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86YWI3MWQ3MDA4ZTg5ZDZhMmFkOTA3YWU2MjgwMzBjOGI6Nzo1YzM4OjVmMDc1NzM4MGM2NmU1OGJhYjQwNzEzMzlkOWNmMjhhNzkxNDk5MmRmMDJmZTk1N2VlNjNkN2FhZTcyNjBkYjE6cDpUOk4&data=05%7C02%7CJinwoo.Hwang%40sas.com%7Ce592270eda4f4beab5d908de368ed82a%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008184338090434%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=2TF5E9XcVpEkb1gkyjYxTb9UgHvn%2F9kYIsSEUdCnQu4%3D&reserved=0><https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect.checkpoint.com%2Fv2%2Fr01%2F___https%3A%2F%2Fnam02.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fgithub.com%252Fapache%252Fgeode%252Fpull%252F7941*23issuecomment-3617666432%26data%3D05%257C02%257CJinwoo.Hwang%2540sas.com%257C32961c14aeee46edf7a308de3430558c%257Cb1c14d5c362545b3a4309552373a0c2f%257C0%257C0%257C639005579398526167%257CUnknown%257CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%253D%253D%257C0%257C%257C%257C%26sdata%3D5yjPttOwctBkDkjKtXLMwCFNu72ffVyu8FV0xN%252Fp2K8%253D%26reserved%3D0___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86ZjcxMDI5Yzk5YWY2OGNiZDYwMDJjYjNlOGJmNTQ0NDA6NzoyY2Q5OjczYWE0ZTAzZTI1OGQzMjE2OGZkZDRiMjNhZTFhZGIyZTU1ZTE0MTU0NWNiNTEwMWJiOTIwMmRmMzVlYTRhNTk6cDpUOk4&data=05%7C02%7CJinwoo.Hwang%40sas.com%7Ce592270eda4f4beab5d908de368ed82a%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008184338097886%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=vRryyvDRY3Wa5HCOVMqDW9XEJlJGzlQiHvDLiBD2Nc0%3D&reserved=0><https://protect.checkpoint.com/v2/r01/___https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7941*23issuecomment-3617666432&data=05%7C02%7CJinwoo.Hwang%40sas.com%7C32961c14aeee46edf7a308de3430558c%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639005579398526167%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=5yjPttOwctBkDkjKtXLMwCFNu72ffVyu8FV0xN%2Fp2K8%3D&reserved=0___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86ZjcxMDI5Yzk5YWY2OGNiZDYwMDJjYjNlOGJmNTQ0NDA6NzoyY2Q5OjczYWE0ZTAzZTI1OGQzMjE2OGZkZDRiMjNhZTFhZGIyZTU1ZTE0MTU0NWNiNTEwMWJiOTIwMmRmMzVlYTRhNTk6cDpUOk4> > > > > 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 > > > > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect.checkpoint.com%2Fv2%2Fr01%2F___http%3A%2F%2FJinwooHwang.com___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86YWU3NGI5MDUyYmY4ZjkwMDNlMWJhMTUzODY2NTRjMjY6NzowMDFiOmFmNzhlZDUxNjg0N2ZiZTBkN2I3NzViNzQxMjkzNjI4MTAzZDE4ZjZlZTk5ZDlkZjMzNmE2MDhjNjVjYWU2ZjQ6cDpUOk4&data=05%7C02%7CJinwoo.Hwang%40sas.com%7Ce592270eda4f4beab5d908de368ed82a%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008184338105004%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=o%2FIDZLnkmKDnnGJcS1i8iS13C9eEGfQaj3rLb0P9s4Y%3D&reserved=0<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect.checkpoint.com%2Fv2%2Fr01%2F___http%3A%2F%2Fjinwoohwang.com%2F___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86YWU3NGI5MDUyYmY4ZjkwMDNlMWJhMTUzODY2NTRjMjY6NzoxN2JhOmYyYWRkYWNmM2ZlMDkxNjg1ZDU0MTc0OGZmMWQ4NjAzZjFkZWRlN2ZlMWI5MzBkNzI2YWFkOTU1YTA1MDRjNzU6cDpUOk4&data=05%7C02%7CJinwoo.Hwang%40sas.com%7Ce592270eda4f4beab5d908de368ed82a%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008184338113140%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=SCbKkL7CROzTvp6pyp13ylwa0oLOGwtLurZKLvEzuvI%3D&reserved=0><https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect.checkpoint.com%2Fv2%2Fr01%2F___http%3A%2F%2FJinwooHwang.com___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86YWU3NGI5MDUyYmY4ZjkwMDNlMWJhMTUzODY2NTRjMjY6NzowMDFiOmFmNzhlZDUxNjg0N2ZiZTBkN2I3NzViNzQxMjkzNjI4MTAzZDE4ZjZlZTk5ZDlkZjMzNmE2MDhjNjVjYWU2ZjQ6cDpUOk4&data=05%7C02%7CJinwoo.Hwang%40sas.com%7Ce592270eda4f4beab5d908de368ed82a%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008184338120519%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=PIlTHJxHTPd5aI8z85KEf8FPPeXYG%2BWxH7P9p4hMd84%3D&reserved=0><https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect.checkpoint.com%2Fv2%2Fr01%2F___http%3A%2F%2FJinwooHwang.com___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86YWU3NGI5MDUyYmY4ZjkwMDNlMWJhMTUzODY2NTRjMjY6NzowMDFiOmFmNzhlZDUxNjg0N2ZiZTBkN2I3NzViNzQxMjkzNjI4MTAzZDE4ZjZlZTk5ZDlkZjMzNmE2MDhjNjVjYWU2ZjQ6cDpUOk4&data=05%7C02%7CJinwoo.Hwang%40sas.com%7Ce592270eda4f4beab5d908de368ed82a%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008184338127298%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=asrEh9N29AGkMOvuQKX0sWBVNiZK0Q2%2Fl5BM1yXiRaY%3D&reserved=0><https://protect.checkpoint.com/v2/r01/___http://JinwooHwang.com___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86YWU3NGI5MDUyYmY4ZjkwMDNlMWJhMTUzODY2NTRjMjY6NzowMDFiOmFmNzhlZDUxNjg0N2ZiZTBkN2I3NzViNzQxMjkzNjI4MTAzZDE4ZjZlZTk5ZDlkZjMzNmE2MDhjNjVjYWU2ZjQ6cDpUOk4> > > > > > > > > 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 > > >
