Re: FindBugs project announced as 'dead', blaims code rot and lack of maintainers

[Timo]

Looks like Bill Pugh was woken up:
https://twitter.com/wpugh/status/795350364291813376

2016-11-06 19:00 GMT+01:00 Gary Gregory :

> The whole post is interesting. Sounds like a fork is inevitable. So much
> work though...
>
> Gary
>
> On Nov 6, 2016 9:32 AM, "Stian Soiland-Reyes"  wrote:
>
> > See
> > https://mailman.cs.umd.edu/pipermail/findbugs-discuss/
> > 2016-November/004321.html
> >
> > In particular the author is not happy about the BCEL integration:
> >
> > > The other major reasons for the FindBugs current bad state:
> > >
> > > 1) The code is very complex, has "organically grown" over a decade, is
> > > not documented and has poor public interfaces. Most of the code
> consists
> > > of the very low level bytecode related stuff, tightly coupled with the
> > > ancient BCEL library, which doesn't scale and is not multi-thread safe.
> > > No one enjoys maintaining this code, at least not me. I see no future
> > > for FindBugs with the BCEL approach, and see no way to get rid of it
> > > without investing lot of effort, and without breaking every detector
> and
> > > possibly many 3rd party tools. This is the biggest issue we have with
> > > FindBugs today, and most likely the root cause for all the evil. This
> > > code can't be fixed, it must be rewritten.
> >
> > ..but the main problem seems to be lack of maintaners.
> >
> >
> > --
> > Stian Soiland-Reyes
> > http://orcid.org/-0001-9842-9718
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>

Re: Deserialization vulnerability in Apache Commons Collection

[Timo]

Hi Deepesh,

there is an ongoing vote to release commons-collections 3.2.2, which
by default prevents InvokerTransformer from being deserialized. You
can find the release notes here:
https://dist.apache.org/repos/dist/dev/commons/collections/RELEASE-NOTES.txt

For further information, please take a look at the ASF blog:
https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread

Timo

2015-11-10 9:05 GMT+01:00 Kapoor, Deepesh <deepesh_kap...@spe.sony.com>:
> Hi Team,
>
> This is regarding "commons-collections Java library". In our applications we 
> are widely using this library and hence looking to urgently patch the fix for 
> vulnerability issue if it is available.
> Searching on internet we found one patch released on Sunday 08th Nov 
> http://svn.apache.org/viewvc?view=revision=1713307
>
> Just wanted to check with you if there is any updated / complied version of 
> commons-collections jar available or going to be released soon which we can 
> directly replace with our existing jar file that provides the fix for the 
> vulnerability issue.
>
> Thanks in advance!
>
>
> Thanks & Regards,
> Deepesh

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [COLLECTIONS] Bad press on twitter following serialization issue

[Timo]

Hello Bernd,

nice article and I would be happy to see this on the ASF blog to point
people to it.

I also found some typos:

"Both research work shows that developers"
should be
"Both research works show that developers"

"final type is checked lot of code"
should be
"final type is checked a lot of code"

"sample payloads which combines classes"
should be
"sample payloads which combine classes"

Timo


2015-11-09 9:36 GMT+01:00 Benedikt Ritter <brit...@apache.org>:
> Hello Bernd,
>
> very nice. I found two typos:
>
> "It is possible to limit the impact when using a custom ObjecrtInputStream
> which overwrites" - should be ObjectInputStream
> "However it should be clear, this is not the only known (and especially not
> yet know) gadget" - should be "and especially not yet known"
>
> I think we can bring this to the ASF Blog via Sally Khudairi (s...@apache.org
> ).
>
> Thanks,
> Benedikt
>
> 2015-11-09 9:16 GMT+01:00 Bernd Eckenfels <e...@zusammenkunft.net>:
>
>> Hello,
>>
>> attached is the draft, thanks for Gary and Gabriel (did I miss any
>> contribution?)
>>
>> I think "Bernd Eckenfels and Gary Gregory for Apache Commons" would be
>> the author (includes a thanks to Gabriel at the end).
>>
>> What is the procedure to get this published?
>>
>> Title? "Apache Commons statement to widespread Javaobject
>> de-serialisation vulnerability"?
>>
>>
>> In their
>> [talk](http://frohoff.github.io/appseccali-marshalling-pickles/)
>> "Marshalling Pickles - how deserializing objects will ruin your day" at
>> AppSecCali2015 Gabriel Lawrence ([@gebl](https://twitter.com/gebl)) and
>> Chris Frohoff ([@frohoff](https://twitter.com/frohoff)) presented
>> various security problems when applications accept serialized objects
>> from untrusted source. A major finding describes a way to execute
>> arbitrary Java functions and even inject manipulated bytecode when
>> using Java Object Serialization (as used in some remote communication
>> and persistence protocols).
>>
>> Build on Frohoff's tool
>> [ysoserial](https://github.com/frohoff/ysoserial), Stephen Breen
>> ([@breenmachine](https://twitter.com/breenmachine)) of Foxglove
>> Security inspected various products like WebSphere, JBoss, Jenkins,
>> WebLogic, and OpenNMS and describes
>> (
>> http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/
>> )
>> for each of them various attack scenarios.
>>
>> Both research work shows that developers put too much trust in Java
>> Object Serialization. Some even de-serialize objects
>> pre-authentication. When deserializing an Object in Java you typically
>> cast it to an expected type, and therefore Java's strict type system
>> will ensure you only get valid object trees. Unfortunately, by the time
>> the type checking happens, platform code has already created and
>> executed significant logic. So, before the final type is checked lot of
>> code is executed from the readObject() methods of various objects, all
>> of which is out of the developer's control. By combining the
>> readObject() methods of various classes which are available on the
>> classpath of the vulnerable application an attacker can execute
>> functions (including calling Runtime.exec() to execute local OS
>> commands).
>>
>> The best protection against this, is to avoid using a complex
>> serialization protocol with untrusted peers. It is possible to limit
>> the impact when using a custom ObjecrtInputStream which overwrites
>> [resolveClass()](
>> http://docs.oracle.com/javase/7/docs/api/java/io/ObjectInputStream.html#resolveClass%28java.io.ObjectStreamClass%29
>> )
>> to implement a whitelist approach. This might however not always be
>> possible, when a framework or application server provides the endpoint.
>> This is rather bad news, as there is no easy fix and applications need
>> to revisit their client-server protocols and overall architecture.
>>
>> In these rather unfortunate situations, people have looked at the
>> sample exploits. Frohoff provided "gadget chains" in sample payloads
>> which combines classes from Groovy runtime, Sprint framework or Apache
>> Commons Collection. It is quite certain that you can combine more
>> classes to exploit this weakness, but those are the chains readily
>> available to attackers today.
>>
>> https://twitter.com/gebl/status/66278660

[LANG] Release notes for 3.4 disappeared

[Timo]

Hello everyone,

I just noticed that the release notes for 3.4 [1] are a 404. Can
someone with access take a look, please?

Thanks
Timo

[1] 
http://commons.apache.org/proper/commons-lang/release-notes/RELEASE-NOTES-3.4.txt

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org