[jira] [Commented] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[
https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15006800#comment-15006800
]
Gary Gregory commented on IO-487:
-
Right, {{accept(MyClass.class)}} is fine as long as we translate that to
{{Class#getName()}} internally.
> SafeObjectInputStream 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.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
>
>
> As discussed on the commons dev list I'd like to contribute my SLING-5288
> code to commons-io. I'll attach a patch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrian Crum updated IO-487: --- Attachment: IO-487.patch Updated patch with Niall's changes. The biggest problem I see with this issue is we have multiple contributers working on different versions of the patches. There needs to be better coordination. > SafeObjectInputStream 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.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. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[
https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15006893#comment-15006893
]
Bertrand Delacretaz commented on IO-487:
The {{IO-487-accept-reject.patch}} uses a different and much simpler (IMO) API
that makes it more foolproof, so I would much prefer that variant.
> SafeObjectInputStream 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.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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15006765#comment-15006765 ] Gary Gregory commented on IO-487: - I would be careful using class objects in the API, because of class loader issues. Internally, we should always use FQ class names, right? > SafeObjectInputStream 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.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 > > > As discussed on the commons dev list I'd like to contribute my SLING-5288 > code to commons-io. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[
https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15006769#comment-15006769
]
Bertrand Delacretaz commented on IO-487:
You mean in methods like {{accept(MyClass.class)}} ?
One can always use {{accept(MyClass.class.getName())}} instead, using the
wildcard syntax. And internally we use the FQCN anyway, so not sure if that's a
problem.
> SafeObjectInputStream 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.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
>
>
> As discussed on the commons dev list I'd like to contribute my SLING-5288
> code to commons-io. I'll attach a patch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[
https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15006769#comment-15006769
]
Bertrand Delacretaz edited comment on IO-487 at 11/16/15 3:22 PM:
--
You mean in methods like {{accept(MyClass.class)}} ?
One can always use {{accept(MyClass.class.getName())}} instead, using the
wildcard syntax. And internally we use the FQCN anyway, so not sure if that's a
problem. As you're going to deserialize those classes they need to be loaded
anyway.
was (Author: bdelacretaz):
You mean in methods like {{accept(MyClass.class)}} ?
One can always use {{accept(MyClass.class.getName())}} instead, using the
wildcard syntax. And internally we use the FQCN anyway, so not sure if that's a
problem.
> SafeObjectInputStream 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.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
>
>
> As discussed on the commons dev list I'd like to contribute my SLING-5288
> code to commons-io. I'll attach a patch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15006693#comment-15006693 ] Joerg Schaible commented on IO-487: --- If you have to declare any accepted class, you might be surprised how many of it you're actually using. It might be good to support ClassNameMatcher implementations that accept: - the primitive types and their boxed variants - very common types like String, UUID, Date, File - any array type if the base type is also allowed - a class hierarchy (e.g. List and derived) - proxy types - (special) lambda types > SafeObjectInputStream 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.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 > > > As discussed on the commons dev list I'd like to contribute my SLING-5288 > code to commons-io. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15006594#comment-15006594 ] Bertrand Delacretaz commented on IO-487: bq. I'd suggest adding the name of the class rejected to the InvalidClassException I intentionally didn't do that as security folks sometimes complain that these sorts of things disclose too much information to an attacker. If adding the name is fine with the usual Commons best practices I'm fine with that. I'll look at your other comments later today, hopefully. > SafeObjectInputStream 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.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 > > > As discussed on the commons dev list I'd like to contribute my SLING-5288 > code to commons-io. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15006598#comment-15006598 ] Emmanuel Bourg commented on IO-487: --- bq. I intentionally didn't do that as security folks sometimes complain that these sorts of things disclose too much information to an attacker. Ok, in this case I suggest adding a comment explaining this choice, otherwise someone may be tempted to change this later without knowing. > SafeObjectInputStream 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.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 > > > As discussed on the commons dev list I'd like to contribute my SLING-5288 > code to commons-io. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[
https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15006676#comment-15006676
]
Bertrand Delacretaz commented on IO-487:
bq. ...any class is rejected unless it's explicitly accepted. Calling reject()
has no real effect on the end result.
I think the IO-487-accept-reject.patch logic makes sense considering the use
of wildcard matchers:
By default nothing is accepted, to force users to think about what they accept.
If you don't call {{accept}}, nothing works and I think it's good. This allows
you to just tell your developers to use {{ValidatingObjectInputStream}} and
they'll discover the rest by themselves.
The most common case (and recommended IMO) is probably to just accept a single
or a few classes, like {{accept(MyClass.class)}} or
{{accept(org.mycompany.safestuff.*)}}. This is a pure whitelisting mode.
If you want a whitelist with a few exceptions you can do something like
{noformat}accept("org.*").reject("org.badguys.*"){noformat}
Such a wide accept pattern is not recommended but works if you know what you're
doing. And the order of the accept/reject calls is not important, reject always
wins which is good for security.
If you want to use a standard blacklist on top of whatever you accept, just to
be on the safe side, you can require your users to always call
{{reject(YOUR_STANDARD_BLACKLIST)}}
Does this make sense?
> SafeObjectInputStream 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.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
>
>
> As discussed on the commons dev list I'd like to contribute my SLING-5288
> code to commons-io. I'll attach a patch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15006702#comment-15006702 ] Emmanuel Bourg commented on IO-487: --- Ok understood I didn't parse the method properly. All classes are rejected by default, and reject() specifies exceptions to what was accept()ed. The javadoc of the accept/reject methods is clear, a few examples in the class javadoc would be good though. > SafeObjectInputStream 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.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 > > > As discussed on the commons dev list I'd like to contribute my SLING-5288 > code to commons-io. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COLLECTIONS-580) Arbitrary remote code execution with InvokerTransformer
[
https://issues.apache.org/jira/browse/COLLECTIONS-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15006612#comment-15006612
]
Michel Schudel commented on COLLECTIONS-580:
Thanks Thomas for the quick fix
> Arbitrary remote code execution with InvokerTransformer
> ---
>
> Key: COLLECTIONS-580
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-580
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 3.0, 4.0
>Reporter: Philippe Marschall
> Fix For: 3.2.2, 4.1
>
> Attachments: COLLECTIONS-580.patch
>
>
> With {{InvokerTransformer}} serializable collections can be build that
> execute arbitrary Java code.
> {{sun.reflect.annotation.AnnotationInvocationHandler#readObject}} invokes
> {{#entrySet}} and {{#get}} on a deserialized collection. If you have an
> endpoint that accepts serialized Java objects (JMX, RMI, remote EJB, ...) you
> can combine the two to create arbitrary remote code execution vulnerability.
> I don't know of a good fix short of removing {{InvokerTransformer}} or making
> it not Serializable. Both probably break existing applications.
> This is not my research, but has been discovered by other people.
> https://github.com/frohoff/ysoserial
> http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[
https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15006723#comment-15006723
]
Emmanuel Bourg commented on IO-487:
---
The base types should be accepted by default I think (primitive wrappers,
arrays, enums, String, Date, URL, File...).
Accepting a hierarchy is a good idea, something like {{acceptInstancesOf()}}
maybe? On the other hand, instead of having a proliferation of methods we could
rely on the Java 8 syntax and write {{accept(c ->
List.class.isAssignableFrom(c))}}.
> SafeObjectInputStream 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.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
>
>
> As discussed on the commons dev list I'd like to contribute my SLING-5288
> code to commons-io. I'll attach a patch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (LANG-1182) Clarify JavaDoc of StringUtils.containsAny()
[
https://issues.apache.org/jira/browse/LANG-1182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated LANG-1182:
--
Fix Version/s: 3.5
> Clarify JavaDoc of StringUtils.containsAny()
>
>
> Key: LANG-1182
> URL: https://issues.apache.org/jira/browse/LANG-1182
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.4
>Reporter: Larry West
>Priority: Minor
> Fix For: 3.5
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> (1) The javadoc for StringUtils.containsAny(CharSequence cs, CharSequence...
> searchCharSequences) confusingly says
> * StringUtils.containsAny("abcd", "ab", "cd") = false
> You can verify this actually returns true by running this:
> if (!StringUtils.containsAny("abcd", "ab", "cd"))
> throw new AssertionError("Third sample from StringUtils 3.4
> javadoc");
> (2) The javadoc for containsAny(final CharSequence cs, final CharSequence
> searchChars) is inadequate, and could easily mislead naive readers to believe
> this containsAny() looks for a matching sequence (substring) rather than
> characters in a set:
> * StringUtils.containsAny("zzabyycdxx", "za") = true
> * StringUtils.containsAny("zzabyycdxx", "by") = true
> In other words, both examples would be equally true for
> StringUtils.contains(). I suggest adding clarifying examples, like:
> * StringUtils.containsAny("zzabyycdxx", "\tx") = true
> * StringUtils.containsAny("zzabyycdxx", "$.#yF") = true
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (LANG-1182) Clarify JavaDoc of StringUtils.containsAny()
[
https://issues.apache.org/jira/browse/LANG-1182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter resolved LANG-1182.
---
Resolution: Fixed
Assignee: Benedikt Ritter
{code}
commit 56907c9a96a50af44415111fcea3e76ce4d1890f
Merge: 4811375 7f0d6b4
Author: Benedikt Ritter
Date: Mon Nov 16 20:16:52 2015 +0100
Merge branch 'LANG-1182'
LANG-1182: Clarify JavaDoc of StringUtils.containsAny(). Thanks to
Larry West for the suggestion and to Pascal Schuhmacher for implementing
it. This fixes #114 from github.
{code}
> Clarify JavaDoc of StringUtils.containsAny()
>
>
> Key: LANG-1182
> URL: https://issues.apache.org/jira/browse/LANG-1182
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.4
>Reporter: Larry West
>Assignee: Benedikt Ritter
>Priority: Minor
> Fix For: 3.5
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> (1) The javadoc for StringUtils.containsAny(CharSequence cs, CharSequence...
> searchCharSequences) confusingly says
> * StringUtils.containsAny("abcd", "ab", "cd") = false
> You can verify this actually returns true by running this:
> if (!StringUtils.containsAny("abcd", "ab", "cd"))
> throw new AssertionError("Third sample from StringUtils 3.4
> javadoc");
> (2) The javadoc for containsAny(final CharSequence cs, final CharSequence
> searchChars) is inadequate, and could easily mislead naive readers to believe
> this containsAny() looks for a matching sequence (substring) rather than
> characters in a set:
> * StringUtils.containsAny("zzabyycdxx", "za") = true
> * StringUtils.containsAny("zzabyycdxx", "by") = true
> In other words, both examples would be equally true for
> StringUtils.contains(). I suggest adding clarifying examples, like:
> * StringUtils.containsAny("zzabyycdxx", "\tx") = true
> * StringUtils.containsAny("zzabyycdxx", "$.#yF") = true
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15007015#comment-15007015 ] Christopher Schultz commented on IO-487: I made a suggestion on the tomcat-user mailing list where we have been discussing the same thing, and are likely to use your implementation once it's complete: allow for the [Whatever]InputStream to be put into a mode where it merely reports (via log @ INFO level) which classes would have been rejected. This will allow a developer to run in this mode to ensure that there aren't any classes being used that are expected to be deserialized during legitimate uses of the application, but aren't matching the currently-configured "accept" criteria. Yes, this can be done by watching for UnsupportedOperationException/InvalidClassException, but it will require the developer to re-build and re-try many times to get all of the various classes taken care of. With this feature, someone could enable the logging, run the application normally, and end up with a complete list of classes that need to be "allowed" by grepping the log file. > SafeObjectInputStream 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.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. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (LANG-1182) Clarify JavaDoc of StringUtils.containsAny()
[
https://issues.apache.org/jira/browse/LANG-1182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated LANG-1182:
--
Summary: Clarify JavaDoc of StringUtils.containsAny() (was: javadoc
correction, clarification on 2 variants of StringUtils.containsAny())
> Clarify JavaDoc of StringUtils.containsAny()
>
>
> Key: LANG-1182
> URL: https://issues.apache.org/jira/browse/LANG-1182
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.4
>Reporter: Larry West
>Priority: Minor
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> (1) The javadoc for StringUtils.containsAny(CharSequence cs, CharSequence...
> searchCharSequences) confusingly says
> * StringUtils.containsAny("abcd", "ab", "cd") = false
> You can verify this actually returns true by running this:
> if (!StringUtils.containsAny("abcd", "ab", "cd"))
> throw new AssertionError("Third sample from StringUtils 3.4
> javadoc");
> (2) The javadoc for containsAny(final CharSequence cs, final CharSequence
> searchChars) is inadequate, and could easily mislead naive readers to believe
> this containsAny() looks for a matching sequence (substring) rather than
> characters in a set:
> * StringUtils.containsAny("zzabyycdxx", "za") = true
> * StringUtils.containsAny("zzabyycdxx", "by") = true
> In other words, both examples would be equally true for
> StringUtils.contains(). I suggest adding clarifying examples, like:
> * StringUtils.containsAny("zzabyycdxx", "\tx") = true
> * StringUtils.containsAny("zzabyycdxx", "$.#yF") = true
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1182) Clarify JavaDoc of StringUtils.containsAny()
[
https://issues.apache.org/jira/browse/LANG-1182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15007153#comment-15007153
]
ASF GitHub Bot commented on LANG-1182:
--
Github user asfgit closed the pull request at:
https://github.com/apache/commons-lang/pull/114
> Clarify JavaDoc of StringUtils.containsAny()
>
>
> Key: LANG-1182
> URL: https://issues.apache.org/jira/browse/LANG-1182
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.4
>Reporter: Larry West
>Priority: Minor
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> (1) The javadoc for StringUtils.containsAny(CharSequence cs, CharSequence...
> searchCharSequences) confusingly says
> * StringUtils.containsAny("abcd", "ab", "cd") = false
> You can verify this actually returns true by running this:
> if (!StringUtils.containsAny("abcd", "ab", "cd"))
> throw new AssertionError("Third sample from StringUtils 3.4
> javadoc");
> (2) The javadoc for containsAny(final CharSequence cs, final CharSequence
> searchChars) is inadequate, and could easily mislead naive readers to believe
> this containsAny() looks for a matching sequence (substring) rather than
> characters in a set:
> * StringUtils.containsAny("zzabyycdxx", "za") = true
> * StringUtils.containsAny("zzabyycdxx", "by") = true
> In other words, both examples would be equally true for
> StringUtils.contains(). I suggest adding clarifying examples, like:
> * StringUtils.containsAny("zzabyycdxx", "\tx") = true
> * StringUtils.containsAny("zzabyycdxx", "$.#yF") = true
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] commons-lang pull request: LANG-1182: adding clarifying examples t...
Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/114 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15007299#comment-15007299 ] Emmanuel Bourg commented on IO-487: --- Or move the throw InvalidClassException to a protected method that can be overridden to log the rejected classes. > SafeObjectInputStream 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.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. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (COMPRESS-327) Support in-memory processing for ZipFile
Brett Kail created COMPRESS-327: --- Summary: Support in-memory processing for ZipFile Key: COMPRESS-327 URL: https://issues.apache.org/jira/browse/COMPRESS-327 Project: Commons Compress Issue Type: New Feature Reporter: Brett Kail Priority: Minor ZipFile (and SevenZFile) currently require a File argument, but it would be nice to support in-memory byte buffers rather than requiring temp files. Perhaps create a new SeekableInputStream class (or SeekableDataInput interface) and add corresponding constructors. For convenience, perhaps also add a utility class that wraps a ByteBuffer and/or byte[] and implements the new interface. (The sevenz package appears to have a similar limitation, so it might make sense to add the support there at the same time, but I personally don't have a need for that.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COLLECTIONS-580) Arbitrary remote code execution with InvokerTransformer
[
https://issues.apache.org/jira/browse/COLLECTIONS-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15007419#comment-15007419
]
Mike Yoder commented on COLLECTIONS-580:
Let me also extend my thanks for the fix. Question: is there an assigned CVE
number for this? I couldn't find one after a quick search.
> Arbitrary remote code execution with InvokerTransformer
> ---
>
> Key: COLLECTIONS-580
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-580
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 3.0, 4.0
>Reporter: Philippe Marschall
> Fix For: 3.2.2, 4.1
>
> Attachments: COLLECTIONS-580.patch
>
>
> With {{InvokerTransformer}} serializable collections can be build that
> execute arbitrary Java code.
> {{sun.reflect.annotation.AnnotationInvocationHandler#readObject}} invokes
> {{#entrySet}} and {{#get}} on a deserialized collection. If you have an
> endpoint that accepts serialized Java objects (JMX, RMI, remote EJB, ...) you
> can combine the two to create arbitrary remote code execution vulnerability.
> I don't know of a good fix short of removing {{InvokerTransformer}} or making
> it not Serializable. Both probably break existing applications.
> This is not my research, but has been discovered by other people.
> https://github.com/frohoff/ysoserial
> http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (SANDBOX-501) Add configurable type conversion support
[ https://issues.apache.org/jira/browse/SANDBOX-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15007178#comment-15007178 ] Benedikt Ritter commented on SANDBOX-501: - Hello Matt, bq. I was wondering if we might have a dialogue concerning commons-beanutils2 in the somewhat near future. Of corse, I'm always interested in feedback. bq. Maybe a chat so we can have a back and forth in real time? The best place for discussions around component design is the development mailing list. Please forgive me, if I don't respond within a day. I have time slots of varying length to work on ASF code and BeanUtils2 is not my top priority at the moment (for example commons-lang3 need a new release) bq. I'd also like to explore a way to provide optional support for Java 8 features without actually requiring Java 8. Commons is very conservative when it comes to the Java versions we support. A lot of the components is still on Java 6. Sandbox components can be developed rather freely. This is, why I'd like to use BeanUtils2 to explore how APIs can be designed with the new features. > Add configurable type conversion support > > > Key: SANDBOX-501 > URL: https://issues.apache.org/jira/browse/SANDBOX-501 > Project: Commons Sandbox > Issue Type: New Feature > Components: BeanUtils2 >Reporter: Benedikt Ritter > Attachments: commons-beanutils2.2015-11-13.patch, > commons-beanutils2.2015-11-14.patch, commons-beanutils2.2015-11-15.patch, > commons-beanutils2.java8.patch > > > BeanUtils1 supports automatic type conversion when setting properties. This > should be added to BeanUtils2. > A problem of the implementation of BeanUtils1 is, that the registry of > converts is cached in the BeanUtils class. BeanUtils2 should provide an API > for creating new instances of the o.a.c.beanutils2.BeanUtils with a > customized typ conversion registry. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SANDBOX-501) Add configurable type conversion support
[ https://issues.apache.org/jira/browse/SANDBOX-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15007178#comment-15007178 ] Benedikt Ritter edited comment on SANDBOX-501 at 11/16/15 7:30 PM: --- Hello Matt, bq. I was wondering if we might have a dialogue concerning commons-beanutils2 in the somewhat near future. Of corse, I'm always interested in feedback. bq. Maybe a chat so we can have a back and forth in real time? The best place for discussions around component design is the development mailing list. Please forgive me, if I don't respond within a day. I have time slots of varying length to work on ASF code and BeanUtils2 is not my top priority at the moment (for example commons-lang3 need a new release) bq. I'd also like to explore a way to provide optional support for Java 8 features without actually requiring Java 8. Commons is very conservative when it comes to the Java versions we support. A lot of the components is still on Java 6. Sandbox components can be developed rather freely. This is, why I'd like to use BeanUtils2 to explore how APIs can be designed with the new features. Again, thank you for your interests in Apache Commons! Regards, Benedikt was (Author: britter): Hello Matt, bq. I was wondering if we might have a dialogue concerning commons-beanutils2 in the somewhat near future. Of corse, I'm always interested in feedback. bq. Maybe a chat so we can have a back and forth in real time? The best place for discussions around component design is the development mailing list. Please forgive me, if I don't respond within a day. I have time slots of varying length to work on ASF code and BeanUtils2 is not my top priority at the moment (for example commons-lang3 need a new release) bq. I'd also like to explore a way to provide optional support for Java 8 features without actually requiring Java 8. Commons is very conservative when it comes to the Java versions we support. A lot of the components is still on Java 6. Sandbox components can be developed rather freely. This is, why I'd like to use BeanUtils2 to explore how APIs can be designed with the new features. > Add configurable type conversion support > > > Key: SANDBOX-501 > URL: https://issues.apache.org/jira/browse/SANDBOX-501 > Project: Commons Sandbox > Issue Type: New Feature > Components: BeanUtils2 >Reporter: Benedikt Ritter > Attachments: commons-beanutils2.2015-11-13.patch, > commons-beanutils2.2015-11-14.patch, commons-beanutils2.2015-11-15.patch, > commons-beanutils2.java8.patch > > > BeanUtils1 supports automatic type conversion when setting properties. This > should be added to BeanUtils2. > A problem of the implementation of BeanUtils1 is, that the registry of > converts is cached in the BeanUtils class. BeanUtils2 should provide an API > for creating new instances of the o.a.c.beanutils2.BeanUtils with a > customized typ conversion registry. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IMAGING-175) Check download release
[ https://issues.apache.org/jira/browse/IMAGING-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter resolved IMAGING-175. - Resolution: Not A Problem There hasn't been a release for commons-imaging, since it has some problems that will require breaking changes to get them fixed. You either have to use sanselan which is the old name of the component or use the latest snapshot from the snapshot archives of the ASF. > Check download release > -- > > Key: IMAGING-175 > URL: https://issues.apache.org/jira/browse/IMAGING-175 > Project: Commons Imaging > Issue Type: Bug >Reporter: Thomas Hartwig > > I am interesting in evaluating Commons Imaging, however there is only the > incubating release available 0.97 for download with old naming scheme > (sanselan) and strange old time stamps when extracting (2009). > In the webpage there is spoke of a snapshot release pre1.0, but there is no > download in no archive. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SANDBOX-501) Add configurable type conversion support
[ https://issues.apache.org/jira/browse/SANDBOX-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15007180#comment-15007180 ] Benedikt Ritter commented on SANDBOX-501: - I'll try to have a look at your patch later this week! Thank you very much! Benedikt > Add configurable type conversion support > > > Key: SANDBOX-501 > URL: https://issues.apache.org/jira/browse/SANDBOX-501 > Project: Commons Sandbox > Issue Type: New Feature > Components: BeanUtils2 >Reporter: Benedikt Ritter > Attachments: commons-beanutils2.2015-11-13.patch, > commons-beanutils2.2015-11-14.patch, commons-beanutils2.2015-11-15.patch, > commons-beanutils2.java8.patch > > > BeanUtils1 supports automatic type conversion when setting properties. This > should be added to BeanUtils2. > A problem of the implementation of BeanUtils1 is, that the registry of > converts is cached in the BeanUtils class. BeanUtils2 should provide an API > for creating new instances of the o.a.c.beanutils2.BeanUtils with a > customized typ conversion registry. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15007292#comment-15007292 ] Bertrand Delacretaz commented on IO-487: For that you can write a ClassNameMatcher that accepts everything and logs names. > SafeObjectInputStream 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.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. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15007171#comment-15007171 ] Benedikt Ritter commented on IO-487: The general design philosophy at commons is, that our components don't write to a log since they are so low level (there are exceptions from this rule however...). > SafeObjectInputStream 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.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. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COLLECTIONS-580) Arbitrary remote code execution with InvokerTransformer
[
https://issues.apache.org/jira/browse/COLLECTIONS-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15006555#comment-15006555
]
Ravi Chamarthy commented on COLLECTIONS-580:
Thanks Thomas for the confirmation.
> Arbitrary remote code execution with InvokerTransformer
> ---
>
> Key: COLLECTIONS-580
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-580
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 3.0, 4.0
>Reporter: Philippe Marschall
> Fix For: 3.2.2, 4.1
>
> Attachments: COLLECTIONS-580.patch
>
>
> With {{InvokerTransformer}} serializable collections can be build that
> execute arbitrary Java code.
> {{sun.reflect.annotation.AnnotationInvocationHandler#readObject}} invokes
> {{#entrySet}} and {{#get}} on a deserialized collection. If you have an
> endpoint that accepts serialized Java objects (JMX, RMI, remote EJB, ...) you
> can combine the two to create arbitrary remote code execution vulnerability.
> I don't know of a good fix short of removing {{InvokerTransformer}} or making
> it not Serializable. Both probably break existing applications.
> This is not my research, but has been discovered by other people.
> https://github.com/frohoff/ysoserial
> http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[
https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bertrand Delacretaz updated IO-487:
---
Attachment: IO-487-accept-reject.patch
Here's IO-487-accept-reject.patch with the suggested accept/reject syntax.
{{ValidatingObjectInputStreamTest}} has a number of examples.
> SafeObjectInputStream 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.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
>
>
> As discussed on the commons dev list I'd like to contribute my SLING-5288
> code to commons-io. I'll attach a patch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[
https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15006559#comment-15006559
]
Bertrand Delacretaz edited comment on IO-487 at 11/16/15 11:51 AM:
---
Here's IO-487-accept-reject.patch with the suggested accept/reject syntax (also
at https://github.com/bdelacretaz/commons-io/tree/IO-487)
{{ValidatingObjectInputStreamTest}} has a number of examples.
was (Author: bdelacretaz):
Here's IO-487-accept-reject.patch with the suggested accept/reject syntax.
{{ValidatingObjectInputStreamTest}} has a number of examples.
> SafeObjectInputStream 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.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
>
>
> As discussed on the commons dev list I'd like to contribute my SLING-5288
> code to commons-io. I'll attach a patch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[
https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15006574#comment-15006574
]
Emmanuel Bourg commented on IO-487:
---
The API looks good to me. I'd suggest adding the name of the class rejected to
the InvalidClassException (there is a constructor for that).
I have one question regarding the accept/reject logic though. If I read the
{{validateClassName}} method properly, any class is rejected unless it's
explicitly accepted. Calling {{reject()}} has no real effect on the end result.
The logic should be adjusted a bit I think, I'm not sure but maybe something
like this:
- if reject is called but not accept, accept everything but the classes rejected
- if accept is called but not reject, reject everything but the classes accepted
- if both accept and reject are called, reject everything but the classes
accepted (it sounds safer this way)
> SafeObjectInputStream 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.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
>
>
> As discussed on the commons dev list I'd like to contribute my SLING-5288
> code to commons-io. I'll attach a patch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (COMPRESS-327) Support in-memory processing for ZipFile
[ https://issues.apache.org/jira/browse/COMPRESS-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damjan Jovanovic updated COMPRESS-327: -- Attachment: seekable-input-stream.txt I wrote a patch precisely for this a few weeks ago (attached), but got no feedback when I emailed it to the dev mailing list, so have been reluctant to commit it. Also the next major version of compress is supposed to support seekable streams, but development on it seems to have been abandoned? > Support in-memory processing for ZipFile > > > Key: COMPRESS-327 > URL: https://issues.apache.org/jira/browse/COMPRESS-327 > Project: Commons Compress > Issue Type: New Feature >Reporter: Brett Kail >Priority: Minor > Attachments: seekable-input-stream.txt > > > ZipFile (and SevenZFile) currently require a File argument, but it would be > nice to support in-memory byte buffers rather than requiring temp files. > Perhaps create a new SeekableInputStream class (or SeekableDataInput > interface) and add corresponding constructors. > For convenience, perhaps also add a utility class that wraps a ByteBuffer > and/or byte[] and implements the new interface. > (The sevenz package appears to have a similar limitation, so it might make > sense to add the support there at the same time, but I personally don't have > a need for that.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15006331#comment-15006331 ] Joerg Schaible commented on IO-487: --- Please use the InvalidClassException with a proper reason (e.g. "security restrictions: class rejected"). We had to detect that even recent jBoss releases start to behave very badly if the object serialization is broken in an unexpected way (we managed to throw a NPE). A restart of jBoss was actually the only way to solve the issue until the next NPE happened. This might apply to other app servers, too. > SafeObjectInputStream 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-name-regex-acceptor.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. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[
https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bertrand Delacretaz updated IO-487:
---
Attachment: IO-487-matchers.patch
Based on all those great ideas, here's a variant (IO-487-matchers.patch) that I
find simpler and more foolproof to use, the single-class setup code is now
{code}
ObjectInputStream ois =
new ValidatingObjectInputStream(is)
.withWhitelist(new FullClassNameMatcher(MyClass.class.getName()))
{code}
And allowing a full package except for a specific class would be
{code}
ObjectInputStream ois =
new ValidatingObjectInputStream(is)
.withWhitelist(new RegexClassNameMatcher("com\\.example\\.foo.*"),
.withBlacklist(com.example.foo.SomeBadClass.class.getName())
{code}
Someone said they prefer include/exclude instead of black/whitelists. I don't
mind, it's just that the latter are common terms in security discussions.
> SafeObjectInputStream 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-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
>
>
> As discussed on the commons dev list I'd like to contribute my SLING-5288
> code to commons-io. I'll attach a patch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[
https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15006477#comment-15006477
]
Bertrand Delacretaz edited comment on IO-487 at 11/16/15 10:37 AM:
---
Or maybe
{code}
ObjectInputStream ois =
new ValidatingObjectInputStream(is)
.accept(com.foo.Foo.class, Integer.class)
.accept("com.bar.Bar*")
.reject("com.baz.*")
{code}
You'd need to process those simplified regex but considering the conventions on
class names it should be sufficient to map dots to {{\.}} and stars to {{.*}}
And also include {{acceptPattern(Pattern p)}} and {{rejectPattern(Pattern p)}}
for edge cases. Or maybe better, {{accept(ClassNameMatcher m)}} and
{{reject(ClassNameMatcher m)}}
was (Author: bdelacretaz):
Or maybe
{code}
ObjectInputStream ois =
new ValidatingObjectInputStream(is)
.accept(com.foo.Foo.class, Integer.class)
.accept("com.bar.Bar*")
.reject("com.baz.*")
{code}
You'd need to process those simplified regex but considering the conventions on
class names it should be sufficient to map dots to {{\.}} and stars to {{.*}}
And also include {{acceptPattern(Pattern p)}} and {{rejectPattern(Pattern p)}}
for edge cases.
> SafeObjectInputStream 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-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
>
>
> As discussed on the commons dev list I'd like to contribute my SLING-5288
> code to commons-io. I'll attach a patch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (COLLECTIONS-580) Arbitrary remote code execution with InvokerTransformer
[
https://issues.apache.org/jira/browse/COLLECTIONS-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15006492#comment-15006492
]
Thomas Neidhart commented on COLLECTIONS-580:
-
collections 3.2.2 has been released yesterday.
A new release for collections4 will be done this week hopefully.
> Arbitrary remote code execution with InvokerTransformer
> ---
>
> Key: COLLECTIONS-580
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-580
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 3.0, 4.0
>Reporter: Philippe Marschall
> Fix For: 3.2.2, 4.1
>
> Attachments: COLLECTIONS-580.patch
>
>
> With {{InvokerTransformer}} serializable collections can be build that
> execute arbitrary Java code.
> {{sun.reflect.annotation.AnnotationInvocationHandler#readObject}} invokes
> {{#entrySet}} and {{#get}} on a deserialized collection. If you have an
> endpoint that accepts serialized Java objects (JMX, RMI, remote EJB, ...) you
> can combine the two to create arbitrary remote code execution vulnerability.
> I don't know of a good fix short of removing {{InvokerTransformer}} or making
> it not Serializable. Both probably break existing applications.
> This is not my research, but has been discovered by other people.
> https://github.com/frohoff/ysoserial
> http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (COLLECTIONS-580) Arbitrary remote code execution with InvokerTransformer
[
https://issues.apache.org/jira/browse/COLLECTIONS-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15006460#comment-15006460
]
Ravi Chamarthy commented on COLLECTIONS-580:
Hi,
Would be interested to know an estimated data on the availability the commons
collections with the fix.
Advance Thanks,
Ravi Chamarthy
> Arbitrary remote code execution with InvokerTransformer
> ---
>
> Key: COLLECTIONS-580
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-580
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 3.0, 4.0
>Reporter: Philippe Marschall
> Fix For: 3.2.2, 4.1
>
> Attachments: COLLECTIONS-580.patch
>
>
> With {{InvokerTransformer}} serializable collections can be build that
> execute arbitrary Java code.
> {{sun.reflect.annotation.AnnotationInvocationHandler#readObject}} invokes
> {{#entrySet}} and {{#get}} on a deserialized collection. If you have an
> endpoint that accepts serialized Java objects (JMX, RMI, remote EJB, ...) you
> can combine the two to create arbitrary remote code execution vulnerability.
> I don't know of a good fix short of removing {{InvokerTransformer}} or making
> it not Serializable. Both probably break existing applications.
> This is not my research, but has been discovered by other people.
> https://github.com/frohoff/ysoserial
> http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[
https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15006466#comment-15006466
]
Emmanuel Bourg commented on IO-487:
---
What about an even simpler syntax like:
{code:java}
ObjectInputStream ois =
new ValidatingObjectInputStream(is)
.withClass(com.foo.Foo.class)
.withClass("com.bar.Bar*")
.withoutPackage("com.baz")
{code}
The various matcher are implementation details that could be hidden behind
friendly named methods.
> SafeObjectInputStream 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-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
>
>
> As discussed on the commons dev list I'd like to contribute my SLING-5288
> code to commons-io. I'll attach a patch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[
https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15006477#comment-15006477
]
Bertrand Delacretaz commented on IO-487:
Or maybe
{code}
ObjectInputStream ois =
new ValidatingObjectInputStream(is)
.accept(com.foo.Foo.class, Integer.class)
.accept("com.bar.Bar*")
.reject("com.baz.*")
{code}
You'd need to process those simplified regex but considering the conventions on
class names it should be sufficient to map dots to {{\.}} and stars to {{.*}}
And also include {{acceptPattern(Pattern p)}} and {{rejectPattern(Pattern p)}}
for edge cases.
> SafeObjectInputStream 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-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
>
>
> As discussed on the commons dev list I'd like to contribute my SLING-5288
> code to commons-io. I'll attach a patch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[
https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15006504#comment-15006504
]
Emmanuel Bourg commented on IO-487:
---
For the simplified pattern syntax we can reuse
{{FilenameUtils.wildcardMatch(String, String)}}, also in commons-io. The
{{accept(String)}} method would not accept a Perl regexp to keep things simple.
> SafeObjectInputStream 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-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
>
>
> As discussed on the commons dev list I'd like to contribute my SLING-5288
> code to commons-io. I'll attach a patch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[
https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15006495#comment-15006495
]
Sebb commented on IO-487:
-
Wildcard matching such as {{withClass("com.bar.Bar*")}} uses a syntax which
AFAIK is not directly supported by Java or Commons.
Implementation will require analysis of the parameter in order to either
convert it to a Java regex or to directly implement the new search syntax.
This is likely to be non-trivial.
Also the syntax will need to be clearly documented and tested.
The other fixed parameter syntaxes look OK.
> SafeObjectInputStream 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-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
>
>
> As discussed on the commons dev list I'd like to contribute my SLING-5288
> code to commons-io. I'll attach a patch.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IO-487) SafeObjectInputStream contribution - restrict which classes can be deserialized
[ https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15006512#comment-15006512 ] Bertrand Delacretaz commented on IO-487: bq. ...we can reuse FilenameUtils.wildcardMatch(String, String)... Ah great, I'll implement the accept/reject variant now. > SafeObjectInputStream 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-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 > > > As discussed on the commons dev list I'd like to contribute my SLING-5288 > code to commons-io. I'll attach a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (COMPRESS-327) Support in-memory processing for ZipFile
[ https://issues.apache.org/jira/browse/COMPRESS-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15008154#comment-15008154 ] Brett Kail commented on COMPRESS-327: - The patch seems to be missing the new(?) SeekableInputStream and SeekableFileInputStream classes, but the changes seem to satisfy the request, so they seem reasonable to me :-). > Support in-memory processing for ZipFile > > > Key: COMPRESS-327 > URL: https://issues.apache.org/jira/browse/COMPRESS-327 > Project: Commons Compress > Issue Type: New Feature >Reporter: Brett Kail >Priority: Minor > Attachments: seekable-input-stream.txt > > > ZipFile (and SevenZFile) currently require a File argument, but it would be > nice to support in-memory byte buffers rather than requiring temp files. > Perhaps create a new SeekableInputStream class (or SeekableDataInput > interface) and add corresponding constructors. > For convenience, perhaps also add a utility class that wraps a ByteBuffer > and/or byte[] and implements the new interface. > (The sevenz package appears to have a similar limitation, so it might make > sense to add the support there at the same time, but I personally don't have > a need for that.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
