Deserialization filter allows overly permissive package patterns vulnerable to gadget chains

[sfloess]

Location

File: ./src/main/java/org/flossware/commons/util/StringUtil.java
Line: 339

Description

The toCompressedString/fromCompressedString and toString/fromString methods use Java native serialization which is vulnerable to Remote Code Execution (RCE) attacks. While ObjectInputFilter was added in fromStream (line 390-405), the filter only allows org.flossware.*, java.lang.*, and java.util.* packages.

This is still too permissive and can be exploited via gadget chains in java.util classes (e.g., java.util.PriorityQueue, java.util.HashMap with custom Comparators). The methods are deprecated but still present and executable.

Recommendation

1. If these methods must remain until removal, implement a strict whitelist of specific safe classes (not entire packages)
2. Add deep inspection to reject any nested objects from untrusted packages
3. Consider runtime detection of gadget chain patterns
4. Add mandatory security documentation requiring authentication/integrity checks before deserialization
5. Accelerate migration to JSON-based serialization (Jackson with safe default typing disabled)

Severity

CRITICAL - Remote Code Execution risk

Related

Related to but distinct from #216 (which focuses on array type bypass). This issue addresses the broader problem of overly permissive package-level filtering.

[sfloess]

Iteration #2 Fix Review - REJECTED (Score 7.5/10)

What Works ✅

• 29 comprehensive security tests added
• Whitelist + blacklist + DoS limits architecture
• Blocks 71% of known gadget chains (12/17)

Critical Gaps ❌

1. Missing JDK gadget classes:

   • java.lang.invoke.SerializedLambda (lambda gadget exploit, RCE)
   • sun.reflect.annotation.AnnotationInvocationHandler (CVE-2017-3241, known RCE)

2. Overly broad whitelist: org.flossware.* allows all 23 project classes without individual validation

3. Missing security tests: No tests for lambda or annotation gadgets

Required for Approval (→ 9/10)

1. Add SerializedLambda to DANGEROUS_CLASSES blacklist
2. Add AnnotationInvocationHandler to DANGEROUS_CLASSES blacklist
3. Replace org.flossware.* wildcard with explicit enumeration of safe classes
4. Add security tests for lambda and annotation gadgets

Close to production-ready - just needs these 4 critical fixes!