Hi Sai, Thank you for your detailed evaluation and for sharing your insights. I’m grateful for your effort in identifying the shortcomings of my initial design and for guiding me toward a more robust approach. Your expertise has been instrumental in improving the solution.
I appreciate your perspective on multi-tenancy and the trade-offs between peer-to-peer and client-server setups. It provides valuable context for the design decisions. I’m glad to hear that you view PR-7966 as a strong solution addressing both security and multi-tenancy concerns. I’d be happy to provide any additional context or collaborate further to support the review. Thanks again for your guidance and feedback; it’s truly appreciated. Best regards, Jinwoo Hwang (he/him/his) SAS® Research and Development http://JinwooHwang.com<http://jinwoohwang.com/> From: Sai Boorlagadda <[email protected]> Date: Tuesday, December 9, 2025 at 12:39 PM To: [email protected] <[email protected]> Subject: Re: PR 7941 - introduces session deserialization discussion EXTERNAL Hi Jinwoo, Great point on multi-tenancy. I am not sure what's more desirable architecture specifically for session mgmt. As you can see Geode has (peer-to-peer, where app servers embed cache servers) vs client-server. Assuming teams use client-server to avoid heavy memory requirements on the peer-to-peer setup. https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect.checkpoint.com%2Fv2%2Fr01%2F___https%3A%2F%2Fgeode.apache.org%2Fdocs%2Fguide%2F115%2Ftools_modules%2Fhttp_session_mgmt%2Ftomcat_setting_up_the_module.html___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86MmJmYmM4Njc2YTJkM2U5MjQzN2Y0M2NkYmFmY2I3ZjY6NzphNDI2OjIzZjhlMWQ1NGEwNWM5OWFiMTQwZGVjNGUxNGNhODQ4YzZlOGMwNDdlZjBhYjMyOWI0ODJkNzdkNmIzMTNkYWM6cDpUOk4&data=05%7C02%7CJinwoo.Hwang%40sas.com%7C30ff4f3ecaab44505a9508de3749d4d6%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008987463079201%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=N9uiOAQmCV%2FRbq%2BQs%2BCl5CHuGL%2Bfxi4m5dJEeWFmdVc%3D&reserved=0<https://protect.checkpoint.com/v2/r01/___https://geode.apache.org/docs/guide/115/tools_modules/http_session_mgmt/tomcat_setting_up_the_module.html___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86MmJmYmM4Njc2YTJkM2U5MjQzN2Y0M2NkYmFmY2I3ZjY6NzphNDI2OjIzZjhlMWQ1NGEwNWM5OWFiMTQwZGVjNGUxNGNhODQ4YzZlOGMwNDdlZjBhYjMyOWI0ODJkNzdkNmIzMTNkYWM6cDpUOk4> So I think PR-7966 (later approach) is much more superior solution and address the security and multi-tenancy concerns. Unless there is a pushback from community I am happy to review 7966 and move forward. Sai On 2025/12/09 14:06:43 Jinwoo Hwang via dev wrote: > Hello team, > > My apologies for the incorrect PR link earlier. Here’s the correct one: > > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fgeode%2Fpull%2F7966&data=05%7C02%7CJinwoo.Hwang%40sas.com%7C30ff4f3ecaab44505a9508de3749d4d6%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008987463092679%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=jHEHGLcovhXkd50beuJgwh5ZdTC6K9U8oz%2B%2FrU7NhWo%3D&reserved=0<https://github.com/apache/geode/pull/7966> > > > > 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___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86MmJmYmM4Njc2YTJkM2U5MjQzN2Y0M2NkYmFmY2I3ZjY6Nzo3ZDQxOmUzYjYwMTBiNWY5YTkxNGUyZTJkODZmYzRmZjc0NWJjYjQ0OTY2YTEyODc3NjJlMDNlM2Y4MjJlOWQ3YWI1ZWU6cDpUOk4&data=05%7C02%7CJinwoo.Hwang%40sas.com%7C30ff4f3ecaab44505a9508de3749d4d6%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008987463101130%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=PzpjuXOZjgqOGNjFibpL71knsM24XJQ4zEbnkOy2gLo%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___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86MmJmYmM4Njc2YTJkM2U5MjQzN2Y0M2NkYmFmY2I3ZjY6NzoxMmQwOmFiZmRhNWY2ODI4YzFlZTE1YTcyMjBhNjZjNGI0N2VjNDBkOGZmMjcwYjFiMDMyNDQwYjM3MTVmOWVhY2YzZWU6cDpUOk4&data=05%7C02%7CJinwoo.Hwang%40sas.com%7C30ff4f3ecaab44505a9508de3749d4d6%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008987463109392%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=mTwtovKHVhs6j%2FWh%2BTzgTkUoh5KR37yzTpEBWQrnx5o%3D&reserved=0><https://protect.checkpoint.com/v2/r01/___http://JinwooHwang.com___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86MmJmYmM4Njc2YTJkM2U5MjQzN2Y0M2NkYmFmY2I3ZjY6Nzo3ZDQxOmUzYjYwMTBiNWY5YTkxNGUyZTJkODZmYzRmZjc0NWJjYjQ0OTY2YTEyODc3NjJlMDNlM2Y4MjJlOWQ3YWI1ZWU6cDpUOk4> > > > > From: Jinwoo Hwang <[email protected]> > Date: Monday, December 8, 2025 at 11:06 PM > To: [email protected] <[email protected]> > Subject: Re: PR 7941 - introduces session deserialization discussion > > Hi Sai, > > I've submitted PR #7966 implementing application-level deserialization > security model for Apache Geode session management using Java's standard > ObjectInputFilter API (JEP 290). > > Key Points: > -Implementation: 9 lines of production code > -Testing: 52 comprehensive tests (all passing) > -Security: Blocks 26 gadget classes + 10 dangerous package patterns (RCE + > DoS prevention) > > Architecture: > Each web application configures its own deserialization filter via web.xml - > providing per-application security isolation without cluster configuration > changes. This aligns with Geode's existing fine-grained SecurityManager model > (per-region/per-key authorization). > > Advantages over alternatives: > -vs PR-7941: 9 lines vs 939, standard API vs custom, flexible config vs > hardcoded > -vs TCCL approach: Application-level isolation vs cluster-wide shared policy > -Aligns with OWASP guidance on deserialization security > > Example Configuration: > <context-param> > <param-name>serializable-object-filter</param-name> > <param-value>com.myapp.**;java.lang.**;!*</param-value> > </context-param> > > > PR link: > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FJinwooHwang%2Fgeode%2Fpull%2F7966&data=05%7C02%7CJinwoo.Hwang%40sas.com%7C30ff4f3ecaab44505a9508de3749d4d6%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008987463118424%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=QOzBqSNMTNxSVgJgLR8Yv9JK%2FYW4oiCND6TiiAdSFHg%3D&reserved=0<https://github.com/JinwooHwang/geode/pull/7966> > > Happy to discuss or make any adjustments based on your feedback. > > > 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___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86MmJmYmM4Njc2YTJkM2U5MjQzN2Y0M2NkYmFmY2I3ZjY6NzoyODU0OmFiOTM0ZDEzNDUwNzMyZDQzYTVmMWY4NDgzYmNhMWIxMTY0ODhiMWZmYjFmMzNkMzdhMDg2ZDFkODVlNWQ0MjU6cDpUOk4&data=05%7C02%7CJinwoo.Hwang%40sas.com%7C30ff4f3ecaab44505a9508de3749d4d6%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008987463126315%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=OXozDm9%2Fuo8dWgER0l3UFCQSnYYgub3Hat39Hor6N%2BY%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___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86MmJmYmM4Njc2YTJkM2U5MjQzN2Y0M2NkYmFmY2I3ZjY6NzpmODdlOmQ4ODhjMTg5YTFmODBkMjEwODJhZWE2MTAzM2I0Y2Y5ODEyNmZiOWY1YzE0YzdmODI1ZTQ2ODNjMDY3YzJhOTA6cDpUOk4&data=05%7C02%7CJinwoo.Hwang%40sas.com%7C30ff4f3ecaab44505a9508de3749d4d6%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008987463134090%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2FVg4MTQg9j6miiXP08yEfIWKaMJWePENTM1WJk0X%2FDw%3D&reserved=0><https://protect.checkpoint.com/v2/r01/___http://JinwooHwang.com___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86MmJmYmM4Njc2YTJkM2U5MjQzN2Y0M2NkYmFmY2I3ZjY6NzoyODU0OmFiOTM0ZDEzNDUwNzMyZDQzYTVmMWY4NDgzYmNhMWIxMTY0ODhiMWZmYjFmMzNkMzdhMDg2ZDFkODVlNWQ0MjU6cDpUOk4> > > > > From: Jinwoo Hwang via dev <[email protected]> > Date: Monday, December 8, 2025 at 5:24 PM > To: [email protected] <[email protected]> > Cc: Jinwoo Hwang <[email protected]> > Subject: Re: PR 7941 - introduces session deserialization discussion > > EXTERNAL > > 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 > > https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect.checkpoint.com%2Fv2%2Fr01%2F___http%3A%2F%2FJinwooHwang.com___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86YTFhYzA1NTM4NzUwY2JkNzdlMjg3ZDllZjliYWVlMGE6NzozYzM4OjQ2NjJlYmIyNGQyZTEyMDZhZGM3ZWI2OWM3OGZiMDU1ZmRmYjQxZmY4YWI2ZGExNzJiNGEzMDhmNmYwZTBkYmQ6cDpUOk4&data=05%7C02%7CJinwoo.Hwang%40sas.com%7C30ff4f3ecaab44505a9508de3749d4d6%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008987463141208%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Q7WH5ae3Cd%2FKcHLjbovrLXR3ZmQL%2BSJyijBRifdgpkI%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___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86YTFhYzA1NTM4NzUwY2JkNzdlMjg3ZDllZjliYWVlMGE6Nzo2ZTM4OjNlZGUzMDQwZmZmNjg4NmYzOWUzZDU5Yzc5NDliN2MzYTA4NTQyMTFjMmZlMDljNWIzMDI4ZWUwNjRiMTQ3MjE6cDpUOk4&data=05%7C02%7CJinwoo.Hwang%40sas.com%7C30ff4f3ecaab44505a9508de3749d4d6%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008987463148219%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=hdmVo1UZQ%2FDCS3o6CejxIh0Qg5AX0pkNR3W8qCypgNc%3D&reserved=0><https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect.checkpoint.com%2Fv2%2Fr01%2F___http%3A%2F%2FJinwooHwang.com___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86YTFhYzA1NTM4NzUwY2JkNzdlMjg3ZDllZjliYWVlMGE6NzozYzM4OjQ2NjJlYmIyNGQyZTEyMDZhZGM3ZWI2OWM3OGZiMDU1ZmRmYjQxZmY4YWI2ZGExNzJiNGEzMDhmNmYwZTBkYmQ6cDpUOk4&data=05%7C02%7CJinwoo.Hwang%40sas.com%7C30ff4f3ecaab44505a9508de3749d4d6%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008987463155258%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=nGbvJomKiCO2m186GsPNVTd%2Fh3E6yn3BMy6OIMlfI%2BA%3D&reserved=0><https://protect.checkpoint.com/v2/r01/___http://JinwooHwang.com___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86YTFhYzA1NTM4NzUwY2JkNzdlMjg3ZDllZjliYWVlMGE6NzozYzM4OjQ2NjJlYmIyNGQyZTEyMDZhZGM3ZWI2OWM3OGZiMDU1ZmRmYjQxZmY4YWI2ZGExNzJiNGEzMDhmNmYwZTBkYmQ6cDpUOk4> > > > > 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%7C30ff4f3ecaab44505a9508de3749d4d6%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008987463164106%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=D4m01YffyqVzYbkQujO28pahXncfUt3edasvP5mJHa4%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%7C30ff4f3ecaab44505a9508de3749d4d6%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008987463172127%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=nK0umPCLkDBK3VZ%2FSl1QzKuyMZVczUE53DUzmxlrYjU%3D&reserved=0><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%7C30ff4f3ecaab44505a9508de3749d4d6%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008987463187594%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Dx7sxsWyMnA%2FUqv1SLk5iNaMOJ5VE4Si7od3d1Qj6oA%3D&reserved=0><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%7C30ff4f3ecaab44505a9508de3749d4d6%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008987463203115%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=65dTNFY0De09k6xhxoLjnwasNmfrqNVd5DLAbzEqUF4%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%7C30ff4f3ecaab44505a9508de3749d4d6%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008987463212592%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=M7UXqkv6C3FQx0yS3QX5rOI43Q2ZCtsMXS%2F%2BYI2RlR8%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%7C30ff4f3ecaab44505a9508de3749d4d6%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008987463220230%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=W7uDi2%2BBJPunSjM3JiM985G3QSYXtiYOCtMdsVLA5Zs%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%7C30ff4f3ecaab44505a9508de3749d4d6%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008987463227463%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ftfgNK3abzo6ssYG6ATT4cqFqFpBxcBPpNkHbdk%2FE%2B0%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%7C30ff4f3ecaab44505a9508de3749d4d6%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008987463237991%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=rD4LuvHhvdBOsl5bbq%2B%2FFfUn5y%2F6drYBtCEg0izVdgQ%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%7C30ff4f3ecaab44505a9508de3749d4d6%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008987463245344%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=cqU6JJb8jjzQhNJetLh2zgnM7FEEDlQbtZquiXA5qOM%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%7C30ff4f3ecaab44505a9508de3749d4d6%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008987463252215%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=wW8Ph5jvMTU8lrbII4sfeab1zBbojT9usAl2XdIlvDI%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%7C30ff4f3ecaab44505a9508de3749d4d6%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008987463259290%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=RVi8bbMHE8o%2F98ve5hJi6L2eNACnoCJhI6w145MDivE%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-<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>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%7C30ff4f3ecaab44505a9508de3749d4d6%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008987463266354%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=1ceTdMemMMh4Q2EmG8oAdHahhAhSA5vvXmfSJC9%2FiJs%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%252Fprotect.checkpoint.com%252Fv2%252Fr01%252F___https%253A%252F%252Fnam02.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Fgithub.com%25252Fapache%25252Fgeode%25252Fpull%25252F7941*23issuecomment-3617666432%2526data%253D05%25257C02%25257CJinwoo.Hwang%252540sas.com%25257C32961c14aeee46edf7a308de3430558c%25257Cb1c14d5c362545b3a4309552373a0c2f%25257C0%25257C0%25257C639005579398526167%25257CUnknown%25257CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%25253D%25253D%25257C0%25257C%25257C%25257C%2526sdata%253D5yjPttOwctBkDkjKtXLMwCFNu72ffVyu8FV0xN%25252F___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86MmJmYmM4Njc2YTJkM2U5MjQzN2Y0M2NkYmFmY2I3ZjY6NzoyYzBlOmRkOWM3MGU1ZWM2ZDYxOWZiNmZiY2U4NzY1N2JjZjA2YjVkNDIzYmUzOWFjNzEwY2U2ZGJmMzIxNzlkMWFmMDk6cDpUOk4&data=05%7C02%7CJinwoo.Hwang%40sas.com%7C30ff4f3ecaab44505a9508de3749d4d6%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008987463273262%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=NozvoX%2BTfytFhwEJGAiG0Ly7KAH00Sd4l07jmAvHpIs%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%7C30ff4f3ecaab44505a9508de3749d4d6%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008987463280299%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=s11JC7U93c7wXhRuumGCqYZxbwmKhQVGCt970yU4Y%2FY%3D&reserved=0>p2K8%253D%26reserved%3D0___.YzJ1OnNhc2luc3RpdHV0ZTpjOm86ZjcxMDI5Yzk5YWY2OGNiZDYwMDJjYjNlOGJmNTQ0NDA6NzoyY2Q5OjczYWE0ZTAzZTI1OGQzMjE2OGZkZDRiMjNhZTFhZGIyZTU1ZTE0MTU0NWNiNTEwMWJiOTIwMmRmMzVlYTRhNTk6cDpUOk4&data=05%7C02%7CJinwoo.Hwang%40sas.com%7Cd188fcb8162d4138079808de36a89383%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008294841200362%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Z5U89MYLssCAfDM8XyMDGDQ0sO1kCoany2tDn5s%2Fq4g%3D&reserved=0> > > > > > > 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%7C30ff4f3ecaab44505a9508de3749d4d6%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008987463287249%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=x8fvNZ60cwD3acQJ0N31ugj0M4a7f07FOUifB1BMzBI%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%7C30ff4f3ecaab44505a9508de3749d4d6%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008987463294454%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=V%2Fho6oBBY5JUEKVb7TRUWB7wlg4P2HmZON7nglmqWw4%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%7C30ff4f3ecaab44505a9508de3749d4d6%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008987463301461%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=c7L0pRa1RxInNfp45M7R9tyNh9DzAlwBynIT1IFDv%2BQ%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%7C30ff4f3ecaab44505a9508de3749d4d6%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008987463308199%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=6LI%2BIZjeavP95080ooFIXgimf%2BZK1MySF3IXzCeo870%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%7C30ff4f3ecaab44505a9508de3749d4d6%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008987463314783%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=2y8irQPTSd3GWC7RN4%2FgPsRrbkGQMDAmoJ66NYF5%2FIU%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%7C30ff4f3ecaab44505a9508de3749d4d6%7Cb1c14d5c362545b3a4309552373a0c2f%7C0%7C0%7C639008987463322668%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=2WJX2jqga8Un09Aifcl7L2lowP4Pn0o2mEuXX4UqhiA%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 > > > > > >
