[jira] [Commented] (COLLECTIONS-580) Arbitrary remote code execution with InvokerTransformer

2015-11-19 Thread Thomas Neidhart (JIRA) 

[ 
https://issues.apache.org/jira/browse/COLLECTIONS-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15013112#comment-15013112
 ] 

Thomas Neidhart commented on COLLECTIONS-580:
-

Hmm I feared that it would be too easy to create other, similar exploits with 
still serializable classes.

btw. for the same DOS attack, the guava lib might be exploitable as well. The 
lib also provides predicates and functions that can be chained in a way or 
another and are serializable.

> 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] (MATH-1293) Tabulating the logarithmic factorial

2015-11-19 Thread Aleksei Dievskii (JIRA) 

[ 
https://issues.apache.org/jira/browse/MATH-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15013226#comment-15013226
 ] 

Aleksei Dievskii commented on MATH-1293:


At that moment, no. I was operating under assumption that I can send messages 
to the list without being subscribed. Presently, I have successfully subscribed 
and re-sent my message.

> Tabulating the logarithmic factorial
> 
>
> Key: MATH-1293
> URL: https://issues.apache.org/jira/browse/MATH-1293
> Project: Commons Math
>  Issue Type: Improvement
>Affects Versions: 3.5
>Reporter: Aleksei Dievskii
>Priority: Minor
>  Labels: feature, patch
> Attachments: factlog.patch
>
>
> Presently, CombinatoricsUtils#factorialLog is calculated via a tabulated 
> value for the first 21 entries, and for the rest it employs linear-complexity 
> direct summing. For the factorial-heavy computations this can be rather 
> painful. I propose a patch which allocates additional 16KB of tabulated 
> log-factorial values, allowing very fast (constant complexity) computation 
> for arguments up to 17000, and delegating to the log-gamma for the rest. 
> Benchmarks show a speed-up of up to 200x.



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

[jira] [Commented] (IO-487) ValidatingObjectInputStream contribution - restrict which classes can be deserialized

2015-11-19 Thread Kristian Rosenvold (JIRA) 

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

Kristian Rosenvold commented on IO-487:
---

Yes please !


> 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.



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

[jira] [Commented] (IO-487) ValidatingObjectInputStream contribution - restrict which classes can be deserialized

2015-11-19 Thread Bertrand Delacretaz (JIRA) 

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

Bertrand Delacretaz commented on IO-487:


Ran the Cobertura coverage with "mvn site", 
{{target/site/cobertura/index.html}} reports 100% coverage for the 
{{org.apache.commons.io.serialization}} package.

Should I add an item to {{src/changes/changes.xml}} myself, or how does that 
work?

> 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.



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

[jira] [Updated] (IO-487) ValidatingObjectInputStream contribution - restrict which classes can be deserialized

2015-11-19 Thread Bertrand Delacretaz (JIRA) 

 [ 
https://issues.apache.org/jira/browse/IO-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bertrand Delacretaz updated IO-487:
---
Description: 
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

  was:As discussed on the commons dev list I'd like to contribute my SLING-5288 
code to commons-io. I'll attach a patch.


> 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)

[jira] [Commented] (IO-487) ValidatingObjectInputStream contribution - restrict which classes can be deserialized

2015-11-19 Thread Bertrand Delacretaz (JIRA) 

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

Bertrand Delacretaz commented on IO-487:


bq. If you have to declare any accepted class, you might be surprised how many 
of it you're actually using ([~joehni]) .

Indeed. I have added a {{MoreComplexObjectTest}} [1] which demonstrates this, 
using 3 variants: trust {{java.lang}} packages, trust all {{java}} packages, 
and a blacklist-only mode.

The "trust java" variant is not too bad:

{code}
new ValidatingObjectInputStream(inputStream)
  .accept(MoreComplexObject.class)
  .accept("java.*","[Ljava.*")
{code}

But of course it depends on one's concrete cases.

[1] 
https://svn.apache.org/repos/asf/commons/proper/io/trunk/src/test/java/org/apache/commons/io/serialization/MoreComplexObjectTest.java

> 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)

[jira] [Commented] (IO-487) ValidatingObjectInputStream contribution - restrict which classes can be deserialized

2015-11-19 Thread Bertrand Delacretaz (JIRA) 

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

Bertrand Delacretaz commented on IO-487:


Done, http://svn.apache.org/r1715240

> 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.



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

[jira] [Closed] (LANG-1181) MultilineRecursiveToStringStyle is not public

2015-11-19 Thread Henri Yandell (JIRA) 

 [ 
https://issues.apache.org/jira/browse/LANG-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Henri Yandell closed LANG-1181.
---
Resolution: Duplicate

> MultilineRecursiveToStringStyle is not public
> -
>
> Key: LANG-1181
> URL: https://issues.apache.org/jira/browse/LANG-1181
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.builder.*
>Affects Versions: 3.4
>Reporter: Jeff Guinness
>Priority: Minor
>
> The public access modifier is missing from the 
> MultilineRecursiveToStringStyle class. 



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

[jira] [Commented] (LANG-1178) ArrayUtils.removeAll(Object array, int... indices) should do the clone, not its callers

2015-11-19 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/LANG-1178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15014472#comment-15014472
 ] 

ASF GitHub Bot commented on LANG-1178:
--

GitHub user hyandell opened a pull request:

https://github.com/apache/commons-lang/pull/116

Moving the clone inside removeAll(Object,int...);Object per LANG-1178



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/hyandell/commons-lang master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-lang/pull/116.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #116


commit 4df139db7ad0049044458be843d107b935642e84
Author: Henri Yandell 
Date:   2015-11-19T21:58:47Z

Moving the clone inside removeAll(Object,int...);Object per LANG-1178




> ArrayUtils.removeAll(Object array, int... indices) should do the clone, not 
> its callers
> ---
>
> Key: LANG-1178
> URL: https://issues.apache.org/jira/browse/LANG-1178
> Project: Commons Lang
>  Issue Type: Bug
>Reporter: Sebb
>
> The method ArrayUtils.removeAll(Object array, int... indices) currently sorts 
> the input indices array. Therefore the array needs to be cloned; this is 
> currently done by the callers.
> However the sort is an implementation detail of the method, so should be done 
> by the method itself, not by the callers, which is fragile (easy to overlook 
> when creating a new method) and unnecessary.
> This would also allow the method to be more easily changed to a different 
> implementation that does not need to sort the array (e.g. using BitSet)



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

[jira] [Commented] (COLLECTIONS-580) Arbitrary remote code execution with InvokerTransformer

2015-11-19 Thread Thomas Neidhart (JIRA) 

[ 
https://issues.apache.org/jira/browse/COLLECTIONS-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15014694#comment-15014694
 ] 

Thomas Neidhart commented on COLLECTIONS-580:
-

In the collections4 branch, the MultiValuedMap implementations do not use the 
InstantiateFactory anymore.
Committed in r1715302. This required a huge refactoring effort, but should 
definitely be safer as no reflection is used anymore.

> 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)

[GitHub] commons-lang pull request: Moving the clone inside removeAll(Objec...

2015-11-19 Thread hyandell 
GitHub user hyandell opened a pull request:

https://github.com/apache/commons-lang/pull/116

Moving the clone inside removeAll(Object,int...);Object per LANG-1178



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/hyandell/commons-lang master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-lang/pull/116.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #116


commit 4df139db7ad0049044458be843d107b935642e84
Author: Henri Yandell 
Date:   2015-11-19T21:58:47Z

Moving the clone inside removeAll(Object,int...);Object per LANG-1178




---
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) ValidatingObjectInputStream contribution - restrict which classes can be deserialized

2015-11-19 Thread Emmanuel Bourg (JIRA) 

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

Emmanuel Bourg commented on IO-487:
---

What about trusting {{java.lang}} by default? 

> 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)

[jira] [Commented] (COLLECTIONS-580) Arbitrary remote code execution with InvokerTransformer

2015-11-19 Thread Stevie Beck (JIRA) 

[ 
https://issues.apache.org/jira/browse/COLLECTIONS-580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15013329#comment-15013329
 ] 

Stevie Beck commented on COLLECTIONS-580:
-

This reminds me of the the general "SerialDoS" code, published here: 
https://gist.github.com/coekie/a27cc406fc9f3dc7a70d
I am not THAT Java expert, so I just assume, that any application that allows 
deserialization from untrusted input, can be DoS'ed - regardless what libraries 
are included in the classpath.
Just creation of code execution needs more investigation and creativity and the 
need to find suitable gadgets...

> 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] [Comment Edited] (MATH-1293) Tabulating the logarithmic factorial

2015-11-19 Thread Aleksei Dievskii (JIRA) 

[ 
https://issues.apache.org/jira/browse/MATH-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15013226#comment-15013226
 ] 

Aleksei Dievskii edited comment on MATH-1293 at 11/19/15 10:18 AM:
---

At that moment, no. I was operating under assumption that I can send messages 
to the list without being subscribed. Presently, I have successfully subscribed 
and re-sent my message. However, it has yet to appear in the archive or be 
otherwise acknowledged.


was (Author: dievsky):
At that moment, no. I was operating under assumption that I can send messages 
to the list without being subscribed. Presently, I have successfully subscribed 
and re-sent my message.

> Tabulating the logarithmic factorial
> 
>
> Key: MATH-1293
> URL: https://issues.apache.org/jira/browse/MATH-1293
> Project: Commons Math
>  Issue Type: Improvement
>Affects Versions: 3.5
>Reporter: Aleksei Dievskii
>Priority: Minor
>  Labels: feature, patch
> Attachments: factlog.patch
>
>
> Presently, CombinatoricsUtils#factorialLog is calculated via a tabulated 
> value for the first 21 entries, and for the rest it employs linear-complexity 
> direct summing. For the factorial-heavy computations this can be rather 
> painful. I propose a patch which allocates additional 16KB of tabulated 
> log-factorial values, allowing very fast (constant complexity) computation 
> for arguments up to 17000, and delegating to the log-gamma for the rest. 
> Benchmarks show a speed-up of up to 200x.



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

[GitHub] commons-lang pull request: LANG-1186 Fix NullPointerException in F...

2015-11-19 Thread NickManley 
GitHub user NickManley opened a pull request:

https://github.com/apache/commons-lang/pull/117

LANG-1186 Fix NullPointerException in FastDateParser$TimeZoneStrategy

Java 8u60 has a change where `DateFormatSymbols.getZoneStrings` returns 
arrays with 7 elements instead of 5 like it previously had. For some locales, 
the additional two elements are null.

Example from the unit tests:
```
Running org.apache.commons.lang3.time.FastDateParser_TimeZoneStrategyTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.597 sec 
<<< FAILURE! - in 
org.apache.commons.lang3.time.FastDateParser_TimeZoneStrategyTest

testTimeZoneStrategyPattern(org.apache.commons.lang3.time.FastDateParser_TimeZoneStrategyTest)
  Time elapsed: 0.597 sec  <<< ERROR!
java.lang.NullPointerException: null
at 
org.apache.commons.lang3.time.FastDateParser$TimeZoneStrategy.(FastDateParser.java:856)
at 
org.apache.commons.lang3.time.FastDateParser.getLocaleSpecificStrategy(FastDateParser.java:647)
at 
org.apache.commons.lang3.time.FastDateParser.getStrategy(FastDateParser.java:616)
at 
org.apache.commons.lang3.time.FastDateParser.access$100(FastDateParser.java:74)
at 
org.apache.commons.lang3.time.FastDateParser$StrategyParser.letterPattern(FastDateParser.java:230)
at 
org.apache.commons.lang3.time.FastDateParser$StrategyParser.getNextStrategy(FastDateParser.java:214)
at 
org.apache.commons.lang3.time.FastDateParser.init(FastDateParser.java:161)
at 
org.apache.commons.lang3.time.FastDateParser.(FastDateParser.java:147)
at 
org.apache.commons.lang3.time.FastDateParser.(FastDateParser.java:108)
at 
org.apache.commons.lang3.time.FastDateParser_TimeZoneStrategyTest.testTimeZoneStrategyPattern(FastDateParser_TimeZoneStrategyTest.java:31)
```

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/NickManley/commons-lang master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-lang/pull/117.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #117


commit 5556026ed1dc17e70946a4a030842ade3a33baeb
Author: Nick Manley 
Date:   2015-11-20T05:24:05Z

Fix NullPointerException in FastDateParser$TimeZoneStrategy




---
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] [Created] (LANG-1186) NullPointerException in FastDateParser$TimeZoneStrategy

2015-11-19 Thread Nick Manley (JIRA) 
Nick Manley created LANG-1186:
-

 Summary: NullPointerException in FastDateParser$TimeZoneStrategy
 Key: LANG-1186
 URL: https://issues.apache.org/jira/browse/LANG-1186
 Project: Commons Lang
  Issue Type: Bug
  Components: lang.time.*
Reporter: Nick Manley
Priority: Minor


Java 8u60 has a change where {{DateFormatSymbols.getZoneStrings}} returns 
arrays with 7 elements instead of 5 like it previously had. For some locales, 
the additional two elements are null.

{code}
Running org.apache.commons.lang3.time.FastDateParser_TimeZoneStrategyTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.597 sec <<< 
FAILURE! - in org.apache.commons.lang3.time.FastDateParser_TimeZoneStrategyTest
testTimeZoneStrategyPattern(org.apache.commons.lang3.time.FastDateParser_TimeZoneStrategyTest)
  Time elapsed: 0.597 sec  <<< ERROR!
java.lang.NullPointerException: null
at 
org.apache.commons.lang3.time.FastDateParser$TimeZoneStrategy.(FastDateParser.java:856)
at 
org.apache.commons.lang3.time.FastDateParser.getLocaleSpecificStrategy(FastDateParser.java:647)
at 
org.apache.commons.lang3.time.FastDateParser.getStrategy(FastDateParser.java:616)
at 
org.apache.commons.lang3.time.FastDateParser.access$100(FastDateParser.java:74)
at 
org.apache.commons.lang3.time.FastDateParser$StrategyParser.letterPattern(FastDateParser.java:230)
at 
org.apache.commons.lang3.time.FastDateParser$StrategyParser.getNextStrategy(FastDateParser.java:214)
at 
org.apache.commons.lang3.time.FastDateParser.init(FastDateParser.java:161)
at 
org.apache.commons.lang3.time.FastDateParser.(FastDateParser.java:147)
at 
org.apache.commons.lang3.time.FastDateParser.(FastDateParser.java:108)
at 
org.apache.commons.lang3.time.FastDateParser_TimeZoneStrategyTest.testTimeZoneStrategyPattern(FastDateParser_TimeZoneStrategyTest.java:31)
{code}




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

[jira] [Commented] (LANG-1186) NullPointerException in FastDateParser$TimeZoneStrategy

2015-11-19 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/LANG-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15015251#comment-15015251
 ] 

ASF GitHub Bot commented on LANG-1186:
--

GitHub user NickManley opened a pull request:

https://github.com/apache/commons-lang/pull/117

LANG-1186 Fix NullPointerException in FastDateParser$TimeZoneStrategy

Java 8u60 has a change where `DateFormatSymbols.getZoneStrings` returns 
arrays with 7 elements instead of 5 like it previously had. For some locales, 
the additional two elements are null.

Example from the unit tests:
```
Running org.apache.commons.lang3.time.FastDateParser_TimeZoneStrategyTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.597 sec 
<<< FAILURE! - in 
org.apache.commons.lang3.time.FastDateParser_TimeZoneStrategyTest

testTimeZoneStrategyPattern(org.apache.commons.lang3.time.FastDateParser_TimeZoneStrategyTest)
  Time elapsed: 0.597 sec  <<< ERROR!
java.lang.NullPointerException: null
at 
org.apache.commons.lang3.time.FastDateParser$TimeZoneStrategy.(FastDateParser.java:856)
at 
org.apache.commons.lang3.time.FastDateParser.getLocaleSpecificStrategy(FastDateParser.java:647)
at 
org.apache.commons.lang3.time.FastDateParser.getStrategy(FastDateParser.java:616)
at 
org.apache.commons.lang3.time.FastDateParser.access$100(FastDateParser.java:74)
at 
org.apache.commons.lang3.time.FastDateParser$StrategyParser.letterPattern(FastDateParser.java:230)
at 
org.apache.commons.lang3.time.FastDateParser$StrategyParser.getNextStrategy(FastDateParser.java:214)
at 
org.apache.commons.lang3.time.FastDateParser.init(FastDateParser.java:161)
at 
org.apache.commons.lang3.time.FastDateParser.(FastDateParser.java:147)
at 
org.apache.commons.lang3.time.FastDateParser.(FastDateParser.java:108)
at 
org.apache.commons.lang3.time.FastDateParser_TimeZoneStrategyTest.testTimeZoneStrategyPattern(FastDateParser_TimeZoneStrategyTest.java:31)
```

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/NickManley/commons-lang master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-lang/pull/117.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #117


commit 5556026ed1dc17e70946a4a030842ade3a33baeb
Author: Nick Manley 
Date:   2015-11-20T05:24:05Z

Fix NullPointerException in FastDateParser$TimeZoneStrategy




> NullPointerException in FastDateParser$TimeZoneStrategy
> ---
>
> Key: LANG-1186
> URL: https://issues.apache.org/jira/browse/LANG-1186
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.time.*
>Reporter: Nick Manley
>Priority: Minor
>
> Java 8u60 has a change where {{DateFormatSymbols.getZoneStrings}} returns 
> arrays with 7 elements instead of 5 like it previously had. For some locales, 
> the additional two elements are null.
> {code}
> Running org.apache.commons.lang3.time.FastDateParser_TimeZoneStrategyTest
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.597 sec <<< 
> FAILURE! - in 
> org.apache.commons.lang3.time.FastDateParser_TimeZoneStrategyTest
> testTimeZoneStrategyPattern(org.apache.commons.lang3.time.FastDateParser_TimeZoneStrategyTest)
>   Time elapsed: 0.597 sec  <<< ERROR!
> java.lang.NullPointerException: null
>   at 
> org.apache.commons.lang3.time.FastDateParser$TimeZoneStrategy.(FastDateParser.java:856)
>   at 
> org.apache.commons.lang3.time.FastDateParser.getLocaleSpecificStrategy(FastDateParser.java:647)
>   at 
> org.apache.commons.lang3.time.FastDateParser.getStrategy(FastDateParser.java:616)
>   at 
> org.apache.commons.lang3.time.FastDateParser.access$100(FastDateParser.java:74)
>   at 
> org.apache.commons.lang3.time.FastDateParser$StrategyParser.letterPattern(FastDateParser.java:230)
>   at 
> org.apache.commons.lang3.time.FastDateParser$StrategyParser.getNextStrategy(FastDateParser.java:214)
>   at 
> org.apache.commons.lang3.time.FastDateParser.init(FastDateParser.java:161)
>   at 
> org.apache.commons.lang3.time.FastDateParser.(FastDateParser.java:147)
>   at 
> org.apache.commons.lang3.time.FastDateParser.(FastDateParser.java:108)
>   at 
> org.apache.commons.lang3.time.FastDateParser_TimeZoneStrategyTest.testTimeZoneStrategyPattern(FastDateParser_TimeZoneStrategyTest.java:31)
> {code}



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

[jira] [Commented] (LANG-1186) NullPointerException in FastDateParser$TimeZoneStrategy

2015-11-19 Thread Nick Manley (JIRA) 

[ 
https://issues.apache.org/jira/browse/LANG-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15015252#comment-15015252
 ] 

Nick Manley commented on LANG-1186:
---

Created a pull request: https://github.com/apache/commons-lang/pull/117

> NullPointerException in FastDateParser$TimeZoneStrategy
> ---
>
> Key: LANG-1186
> URL: https://issues.apache.org/jira/browse/LANG-1186
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.time.*
>Reporter: Nick Manley
>Priority: Minor
>
> Java 8u60 has a change where {{DateFormatSymbols.getZoneStrings}} returns 
> arrays with 7 elements instead of 5 like it previously had. For some locales, 
> the additional two elements are null.
> {code}
> Running org.apache.commons.lang3.time.FastDateParser_TimeZoneStrategyTest
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.597 sec <<< 
> FAILURE! - in 
> org.apache.commons.lang3.time.FastDateParser_TimeZoneStrategyTest
> testTimeZoneStrategyPattern(org.apache.commons.lang3.time.FastDateParser_TimeZoneStrategyTest)
>   Time elapsed: 0.597 sec  <<< ERROR!
> java.lang.NullPointerException: null
>   at 
> org.apache.commons.lang3.time.FastDateParser$TimeZoneStrategy.(FastDateParser.java:856)
>   at 
> org.apache.commons.lang3.time.FastDateParser.getLocaleSpecificStrategy(FastDateParser.java:647)
>   at 
> org.apache.commons.lang3.time.FastDateParser.getStrategy(FastDateParser.java:616)
>   at 
> org.apache.commons.lang3.time.FastDateParser.access$100(FastDateParser.java:74)
>   at 
> org.apache.commons.lang3.time.FastDateParser$StrategyParser.letterPattern(FastDateParser.java:230)
>   at 
> org.apache.commons.lang3.time.FastDateParser$StrategyParser.getNextStrategy(FastDateParser.java:214)
>   at 
> org.apache.commons.lang3.time.FastDateParser.init(FastDateParser.java:161)
>   at 
> org.apache.commons.lang3.time.FastDateParser.(FastDateParser.java:147)
>   at 
> org.apache.commons.lang3.time.FastDateParser.(FastDateParser.java:108)
>   at 
> org.apache.commons.lang3.time.FastDateParser_TimeZoneStrategyTest.testTimeZoneStrategyPattern(FastDateParser_TimeZoneStrategyTest.java:31)
> {code}



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

[jira] [Issue Comment Deleted] (LANG-1186) NullPointerException in FastDateParser$TimeZoneStrategy

2015-11-19 Thread Nick Manley (JIRA) 

 [ 
https://issues.apache.org/jira/browse/LANG-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nick Manley updated LANG-1186:
--
Comment: was deleted

(was: Created a pull request: https://github.com/apache/commons-lang/pull/117)

> NullPointerException in FastDateParser$TimeZoneStrategy
> ---
>
> Key: LANG-1186
> URL: https://issues.apache.org/jira/browse/LANG-1186
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.time.*
>Reporter: Nick Manley
>Priority: Minor
>
> Java 8u60 has a change where {{DateFormatSymbols.getZoneStrings}} returns 
> arrays with 7 elements instead of 5 like it previously had. For some locales, 
> the additional two elements are null.
> {code}
> Running org.apache.commons.lang3.time.FastDateParser_TimeZoneStrategyTest
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.597 sec <<< 
> FAILURE! - in 
> org.apache.commons.lang3.time.FastDateParser_TimeZoneStrategyTest
> testTimeZoneStrategyPattern(org.apache.commons.lang3.time.FastDateParser_TimeZoneStrategyTest)
>   Time elapsed: 0.597 sec  <<< ERROR!
> java.lang.NullPointerException: null
>   at 
> org.apache.commons.lang3.time.FastDateParser$TimeZoneStrategy.(FastDateParser.java:856)
>   at 
> org.apache.commons.lang3.time.FastDateParser.getLocaleSpecificStrategy(FastDateParser.java:647)
>   at 
> org.apache.commons.lang3.time.FastDateParser.getStrategy(FastDateParser.java:616)
>   at 
> org.apache.commons.lang3.time.FastDateParser.access$100(FastDateParser.java:74)
>   at 
> org.apache.commons.lang3.time.FastDateParser$StrategyParser.letterPattern(FastDateParser.java:230)
>   at 
> org.apache.commons.lang3.time.FastDateParser$StrategyParser.getNextStrategy(FastDateParser.java:214)
>   at 
> org.apache.commons.lang3.time.FastDateParser.init(FastDateParser.java:161)
>   at 
> org.apache.commons.lang3.time.FastDateParser.(FastDateParser.java:147)
>   at 
> org.apache.commons.lang3.time.FastDateParser.(FastDateParser.java:108)
>   at 
> org.apache.commons.lang3.time.FastDateParser_TimeZoneStrategyTest.testTimeZoneStrategyPattern(FastDateParser_TimeZoneStrategyTest.java:31)
> {code}



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

[jira] [Commented] (IO-487) ValidatingObjectInputStream contribution - restrict which classes can be deserialized

2015-11-19 Thread Adrian Crum (JIRA) 

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

Adrian Crum commented on IO-487:


Without the class name, the exception is not useful to the developer. What 
information is being disclosed to an attacker? If I try to exploit code by 
desrializing MyExploit.class, and the exception says "Class 'MyExploit' not 
accepted" - what information have I gained?

> 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.



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

[jira] [Commented] (IO-487) ValidatingObjectInputStream contribution - restrict which classes can be deserialized

2015-11-19 Thread Bertrand Delacretaz (JIRA) 

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

Bertrand Delacretaz commented on IO-487:


I have committed IO-487-accept-reject-2.patch with minor javadoc changes as 
http://svn.apache.org/r1715217

> 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.



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

[jira] [Comment Edited] (IO-487) ValidatingObjectInputStream contribution - restrict which classes can be deserialized

2015-11-19 Thread Bertrand Delacretaz (JIRA) 

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

Bertrand Delacretaz edited comment on IO-487 at 11/19/15 5:11 PM:
--

I have committed {{IO-487-accept-reject-2.patch}} with minor javadoc changes as 
http://svn.apache.org/r1715217


was (Author: bdelacretaz):
I have committed IO-487-accept-reject-2.patch with minor javadoc changes as 
http://svn.apache.org/r1715217

> 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.



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

[jira] [Commented] (IO-487) ValidatingObjectInputStream contribution - restrict which classes can be deserialized

2015-11-19 Thread Bertrand Delacretaz (JIRA) 

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

Bertrand Delacretaz commented on IO-487:


bq. If I try to exploit code by desrializing MyExploit.class, and the exception 
says "Class 'MyExploit' not accepted" - what information have I gained?

None indeed, you are absolutely right. I will modify 
{{ValidatingObjectInputStreamTest}} to include the class name.

> 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.



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

[jira] [Commented] (IO-487) ValidatingObjectInputStream contribution - restrict which classes can be deserialized

2015-11-19 Thread Bertrand Delacretaz (JIRA) 

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

Bertrand Delacretaz commented on IO-487:


Added the class name in the InvalidClassException, as discussed above - 
[~adri...@hlmksw.com] is right that it doesn't provided any additional info to 
a potential attacker. http://svn.apache.org/r1715221

> 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.



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