commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Schultz (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (IO-487) ValidatingObjectInputStream contribution - restrict which classes can be deserialized
Date Fri, 20 Nov 2015 14:49:11 GMT

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

Christopher Schultz commented on IO-487:
----------------------------------------

Instantiating the java.lang.Class object for a class is probably not terribly risky, but there
are certainly scenarios where untrusted classes could be loaded... if their static initializers
are run, there is an opportunity for Bad Things to happen.

But if you were worried about such a thing, you'd use a ClassNameMatcher instead.

To improve performance, one could keep a lookup table of className -> java.lang.Class that
you update only when the class name is acceptable. That would allow you to safely perform
type-checking in a ClassMatcher, but only under certain conditions.

For instance, let's say that I am willing to allow java.util.List and anything that implements
that interface (dangerous, but illustrative). If I have a com.foo.SpecialList, the only way
to check to see whether com.foo.SpecialList will be acceptable is to check the class hierarchy
to see if it implements that interface (or any others registered, of course). I don't see
a way around this unless you want to use commons-bcel to inspect .class files without formally-loading
them into the ClassLoader and risking the execution of their static initializers.

Without something like a ClassMatcher, it will often be very difficult to specify every possible
class that you might want to allow for deserialization.

> ValidatingObjectInputStream contribution - restrict which classes can be deserialized
> -------------------------------------------------------------------------------------
>
>                 Key: IO-487
>                 URL: https://issues.apache.org/jira/browse/IO-487
>             Project: Commons IO
>          Issue Type: Improvement
>          Components: Utilities
>    Affects Versions: 2.4
>            Reporter: Bertrand Delacretaz
>            Priority: Minor
>              Labels: patch
>             Fix For: 2.5
>
>         Attachments: IO-487-2.patch, IO-487-accept-reject-2.patch, IO-487-accept-reject.patch,
IO-487-matchers.patch, IO-487-name-regex-acceptor.patch, IO-487.patch, IO-487.patch, IO-487.patch,
IO-487.patch, IO-487.patch, IO-487.patch, IO-487.patch
>
>
> As discussed on the commons dev list I'd like to contribute my SLING-5288 code to commons-io.
I'll attach a patch.
> _Update: this is committed now, see [1] for an example_.
> [1] https://svn.apache.org/repos/asf/commons/proper/io/trunk/src/test/java/org/apache/commons/io/serialization/MoreComplexObjectTest.java



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message