[jira] [Commented] (OFBIZ-13637) SafeObjectInputStream allowList matches class names as substrings and ships with unescaped dots

["ASF subversion and git services (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OFBIZ-13637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18122244#comment-18122244 ] 

ASF subversion and git services commented on OFBIZ-13637:
---------------------------------------------------------

Commit 5beebac638868c4c676776f692c6191674de11f0 in ofbiz-framework's branch refs/heads/trunk from Mridul Pathak
[ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=5beebac638 ]

Improved: SafeObjectInputStream allowList matches class names as substrings and ships with unescaped dots (OFBIZ-13637)

SafeObjectInputStream decided whether a class could be deserialized with Matcher.find(), which accepts a class name that merely contains an allowed fragment. The allowList shipped in SafeObjectInputStream.properties also used unescaped dots and kept the test-only entries "foo" and "SerializationInjector", so in practice any class whose name contained "java" followed by a character (for example javax.* or javassist.*) or the text "foo" was accepted, instead of only java.* and org.apache.ofbiz.*.

- SafeObjectInputStream now requires the whole class name to match an allowList entry (Matcher.matches()). Object-array class names such as [Ljava.lang.String; are matched on their element type so arrays of allowed classes keep working.
- The shipped allowList escapes its dots, and no longer contains the entries that were only used by tests, which set their own allowList.


> SafeObjectInputStream allowList matches class names as substrings and ships with unescaped dots
> -----------------------------------------------------------------------------------------------
>
>                 Key: OFBIZ-13637
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-13637
>             Project: OFBiz
>          Issue Type: Improvement
>          Components: framework/base
>    Affects Versions: Upcoming Branch, 24.09.07
>            Reporter: Mridul Pathak
>            Assignee: Mridul Pathak
>            Priority: Minor
>
> h3. Problem
> {{SafeObjectInputStream.resolveClass()}} checks a class name against the allowList with {{Matcher.find()}}, which accepts any name that merely *contains* an allowed fragment. The allowList shipped in {{framework/base/config/SafeObjectInputStream.properties}} also overrides the stricter built-in defaults, uses unescaped dots ({{java..*}}, {{org.apache.ofbiz..*}}) and still contains the test-only entries {{foo}} and {{SerializationInjector}}.
> h3. Impact
> In practice any class whose name contains {{java}} followed by a character (e.g. {{javax.*}}, {{javassist.*}}) or the text {{foo}} is accepted, instead of only {{java.*}} and {{org.apache.ofbiz.*}}. The filter therefore admits much more than intended. This is defense-in-depth hardening: exploiting it still requires attacker-controlled serialized data to reach a deserialization point, and none is known to be reachable unauthenticated in a default deployment (the SOAP endpoint is disabled, OFBIZ-12212).
> h3. Fix
> * Require the whole class name to match an allowList entry ({{Matcher.matches()}}); object-array names such as {{[Ljava.lang.String;}} are matched on their element type so arrays of allowed classes keep working.
> * Escape the dots in the shipped allowList and remove the test-only entries (the tests set their own allowList).
> Deployments that add custom classes to allowList should make sure each entry matches the full class name, e.g. {{mycompany\\.foo\\..*}}.
> h3. Release branches
> release24.09 has the identical code and configuration; a backport is planned.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)