On 7 November 2015 at 03:17, Phil Steitz wrote:
> Here is an idea that might break our deadlock re backward
> compatibility, versioning and RERO:
>
> Agree that odd numbered versions have stable APIs - basically adhere
> to Commons rules - no breaks within 3.0, 3.1, ..., 3.x... or 5.0,
> 5.1... bu
On Sun, Nov 8, 2015 at 3:37 PM, Peter Ansell wrote:
> On 9 November 2015 at 09:21, Thomas Neidhart
> wrote:
> > Hi all,
> >
> > please review the proposed fix for this issue here:
> >
> > http://svn.apache.org/viewvc?view=revision&revision=1713307
>
> Those changes look workable to me. The main
On 9 November 2015 at 09:21, Thomas Neidhart wrote:
> Hi all,
>
> please review the proposed fix for this issue here:
>
> http://svn.apache.org/viewvc?view=revision&revision=1713307
Those changes look workable to me. The main issue from my reading is
that real users of serialisation with InvokerT
Hello Gary,
thanks for the offer. I will sent you a edit-link for the article, here
is a comment-only version for people to check:
https://oasis.sandstorm.io/shared/prUMi3zkPMx9bdQ8X2vkX7nt7JW79G3b28IKhS_F8vQ
Greetings
Bernd
Am Sun, 8 Nov 2015
12:20:55 -0800 schrieb Gary Gregory :
> Sounds g
Hi all,
please review the proposed fix for this issue here:
http://svn.apache.org/viewvc?view=revision&revision=1713307
Thanks,
Thomas
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mai
SecurityManager is an ancient part and heavily slows down the JVM. That’s the
reason why almost nobody is using it.
LieGrue,
strub
> Am 08.11.2015 um 20:20 schrieb James Carman :
>
> I think this entire thing can be prevented with a security manager and a
> proper policy in place. Nobody does
On 11/08/2015 09:36 PM, James Carman wrote:
> Oh nasty! I must've met, this is quite a fascinating exploit. I'm going to
> do some digging later today when I am at my computer.
I just figured that the xalan code already does have a system property
to prevent translets from being de-serialized:
Oh nasty! I must've met, this is quite a fascinating exploit. I'm going to
do some digging later today when I am at my computer.
On Sun, Nov 8, 2015 at 3:34 PM Thomas Neidhart
wrote:
> On 11/08/2015 09:11 PM, James Carman wrote:
> > How did we get to the point where someone could invoke arbitrar
On 11/08/2015 09:11 PM, James Carman wrote:
> How did we get to the point where someone could invoke arbitrary bytecode?
Take a look at class TemplatesImpl in
com.sun.org.apache.xalan.internal.xsltc.trax which is part of the oracle
and openjdk jre.
It is serializable and can load so called Transl
Sounds good. I'll be happy to edit if you'd like.
Gary
On Sun, Nov 8, 2015 at 11:19 AM, Bernd Eckenfels
wrote:
> Hello Gary,
>
> if we can release a fixed version quickly I would agree, but it is not
> really needed for a reply to the ongoing FUD.
>
> A statement would be "the dicovered vulnera
On Sun, 8 Nov 2015 14:29:31 +, sebb wrote:
On 8 November 2015 at 13:50, Gilles
wrote:
On Sun, 8 Nov 2015 00:45:38 +, sebb wrote:
So is the idea to change both the Maven artifact ID and package
name
for the beta releases?
i.e. the stable releases would use
Maven AID: commons-math4
How did we get to the point where someone could invoke arbitrary bytecode?
On Sun, Nov 8, 2015 at 2:47 PM James Carman
wrote:
> Runtime.exec can be prevented though
>
> On Sun, Nov 8, 2015 at 2:31 PM Thomas Neidhart
> wrote:
>
>> On 11/08/2015 08:20 PM, James Carman wrote:
>> > I think this enti
Runtime.exec can be prevented though
On Sun, Nov 8, 2015 at 2:31 PM Thomas Neidhart
wrote:
> On 11/08/2015 08:20 PM, James Carman wrote:
> > I think this entire thing can be prevented with a security manager and a
> > proper policy in place. Nobody does that, though
>
> You cannot prevent the us
On 11/08/2015 08:20 PM, James Carman wrote:
> I think this entire thing can be prevented with a security manager and a
> proper policy in place. Nobody does that, though
You cannot prevent the use of reflection for public methods via a
SecurityManager.
If you then look at the different provided p
Hello Gary,
if we can release a fixed version quickly I would agree, but it is not
really needed for a reply to the ongoing FUD.
A statement would be "the dicovered vulnerability is in applications
using JavaObject serialisation from untrusted sources and not
implementing additional precaution li
I think this entire thing can be prevented with a security manager and a
proper policy in place. Nobody does that, though
On Sun, Nov 8, 2015 at 2:10 PM Thomas Neidhart
wrote:
> On 11/08/2015 07:51 PM, James Carman wrote:
> > Couldn't they use the same attack vector to set a system property also
Yes, I guess it should be prevented. Duh!
On Sun, Nov 8, 2015 at 2:16 PM Mark Thomas wrote:
> On 08/11/2015 19:13, James Carman wrote:
> > If they can execute Runtime.exec then they can execute System.setProperty
>
> Yes. But the point you seem to seem to be missing is that if the system
> proper
On 08/11/2015 19:13, James Carman wrote:
> If they can execute Runtime.exec then they can execute System.setProperty
Yes. But the point you seem to seem to be missing is that if the system
property is set such that this attack is blocked, they can't use the
attack to change the system property and
I have already merged the changes into master, and deleted the gh-pages
branch here
https://github.com/mebigfatguy/Naomi
I can add a pull request to Norm to accept these in his repository, if
you like.
On 11/08/2015 01:53 PM, Bernd Eckenfels wrote:
Phil:
I am not happy about proceeding,
If they can execute Runtime.exec then they can execute System.setProperty
On Sun, Nov 8, 2015 at 2:11 PM James Carman
wrote:
> System.setProperty()
>
>
> On Sun, Nov 8, 2015 at 2:10 PM Thomas Neidhart
> wrote:
>
>> On 11/08/2015 07:51 PM, James Carman wrote:
>> > Couldn't they use the same attac
System.setProperty()
On Sun, Nov 8, 2015 at 2:10 PM Thomas Neidhart
wrote:
> On 11/08/2015 07:51 PM, James Carman wrote:
> > Couldn't they use the same attack vector to set a system property also? I
> > do believe that would be possible
>
> for this you need a way to execute code via a de-seria
On 11/08/2015 07:51 PM, James Carman wrote:
> Couldn't they use the same attack vector to set a system property also? I
> do believe that would be possible
for this you need a way to execute code via a de-serialized class.
Right now, the simplest way to do so is via the InvokerTransformer.
There
Phil:
> I am not happy about proceeding, though, in the presence of the
-1
> votes. We like to make decisions by consensus and while this is a
> procedural decision and therefore subject to majority approval, I
> would like to ask those who case negative votes to reconsider.
I have an counter pr
Couldn't they use the same attack vector to set a system property also? I
do believe that would be possible
On Sun, Nov 8, 2015 at 1:46 PM Emmanuel Bourg wrote:
> Le 08/11/2015 15:12, Thomas Neidhart a écrit :
>
> > with the default being: do not de-serialize InvokerTransformer?
> > Then I would
Le 08/11/2015 15:12, Thomas Neidhart a écrit :
> with the default being: do not de-serialize InvokerTransformer?
> Then I would be ok going that route.
I like the idea too. I have a question though: do we use a common
property enabling unsafe deserialization for all commons components, or
do we u
The problem is that we provide them a means to invoke a method on an object.
On Sun, Nov 8, 2015 at 1:43 PM Matt Benson wrote:
> I'm only tangentially following this, but if the problem is that an
> attacker can supply malicious bytecode, then wouldn't a programmatic e.g.
> property be just as ea
I'm only tangentially following this, but if the problem is that an
attacker can supply malicious bytecode, then wouldn't a programmatic e.g.
property be just as easy [for an attacker] to pass in? This would need to
be a transient property, if included, right?
Matt
On Nov 8, 2015 8:50 AM, "Jochen
Hi All:
What about agreeing on a plan before we post anything? My proposal would be
to follow up on an idea posted on the dev ML: Use a system property to
enable the risky feature. This would change the default behavior to
disallow the feature. And possibly add a new config option on the
problemat
With three -1 votes from PMC members, I am not comfortable
proceeding with this. I do not have the cycles right now to rejoin
the Incubator PMC and follow those lists, so this is going to have
to wait for a bit (likely until the holidays) unless someone else is
willing to take on the Incubator tas
If you guys want to put together a blog post about this, Chris and I would
be happy to help. We've tried to be pretty clear to people that this isnt a
problem with the libraries, but something that should be addressed by the
deserializer either by not deserializing from a trusted source or by
hacki
On 11/4/15 5:50 AM, Gilles wrote:
> On Tue, 3 Nov 2015 19:37:48 -0700, Phil Steitz wrote:
>> Here is a tally of the VOTE
>>
>> Commons PMC:
>> +1 from Dave Brosius, Luc Maisonobe, Phil Steitz, Joerg Schaibl,
>> Oliver Heger, Gary Gregory, Niall Pemberton
>> +0 from BenediKt Ritter
>> -0 from
>> -1
Makes sense.
On Sun, Nov 8, 2015 at 3:47 PM, Gary Gregory wrote:
> I like the property option as a stopgap.
>
> Should we add a programatic option so that programmers can also control
> this on a per invoker basis?
>
> Gary
> On Nov 8, 2015 6:43 AM, "Jochen Wiedmann" wrote:
>
>> I like the prop
I like the property option as a stopgap.
Should we add a programatic option so that programmers can also control
this on a per invoker basis?
Gary
On Nov 8, 2015 6:43 AM, "Jochen Wiedmann" wrote:
> I like the property based approach. In particular, because we can
> evaltuate that property withi
I like the property based approach. In particular, because we can
evaltuate that property within
private void readObject
Or, in other words: We can ship a jar that has the vulnerability
disabled by default (property isn't set). However, if the user
attempts to deserialize an InvokerTransforme
Go for it. The license is ASL so that's good.
Gary
On Nov 8, 2015 2:52 AM, "Jochen Wiedmann" wrote:
> As this is fairly new stuff, and you're the one doing it: Go ahead, as you
> like.
>
> Jochen
>
>
> On Sun, Nov 8, 2015 at 10:05 AM, Benedikt Ritter
> wrote:
> > Hi all,
> >
> > I've started wo
On 8 November 2015 at 12:32, Mark Thomas wrote:
> On 08/11/2015 10:18, Thomas Neidhart wrote:
>> On 11/07/2015 11:19 AM, Mark Thomas wrote:
>>> On 07/11/2015 10:13, Thomas Neidhart wrote:
On 11/07/2015 04:25 AM, Bernd Eckenfels wrote:
> Hello,
>
> I tried to raise that concern in
On 8 November 2015 at 13:50, Gilles wrote:
> On Sun, 8 Nov 2015 00:45:38 +, sebb wrote:
>>
>> So is the idea to change both the Maven artifact ID and package name
>> for the beta releases?
>>
>> i.e. the stable releases would use
>>
>> Maven AID: commons-math4
>> package: org.apache.commons.ma
On 11/08/2015 01:32 PM, Mark Thomas wrote:
> On 08/11/2015 10:18, Thomas Neidhart wrote:
>> On 11/07/2015 11:19 AM, Mark Thomas wrote:
>>> On 07/11/2015 10:13, Thomas Neidhart wrote:
On 11/07/2015 04:25 AM, Bernd Eckenfels wrote:
> Hello,
>
> I tried to raise that concern in the me
On Sat, 7 Nov 2015 18:54:59 +0100, Pascal Schumacher wrote:
I guess searching github is more representative:
https://github.com/search?q=org.apache.commons.math3&type=Code&utf8=%E2%9C%93
Thanks. But the number of references is so large
---CUT---
We’ve found 355,855 code results
---CUT---
t
On Sun, 8 Nov 2015 00:45:38 +, sebb wrote:
So is the idea to change both the Maven artifact ID and package name
for the beta releases?
i.e. the stable releases would use
Maven AID: commons-math4
package: org.apache.commons.math4
and beta releases:
Maven AID: commons-math4-beta{n}
package:
On 08/11/2015 10:18, Thomas Neidhart wrote:
> On 11/07/2015 11:19 AM, Mark Thomas wrote:
>> On 07/11/2015 10:13, Thomas Neidhart wrote:
>>> On 11/07/2015 04:25 AM, Bernd Eckenfels wrote:
Hello,
I tried to raise that concern in the message already, but it is probably
worth repeat
On 08/11/2015 03:27, Gabriel Lawrence wrote:
> Howdy,
>
> Thought I'd dive in here. Sorry that things got pointed in your direction
> on this. That was out of our control. Chris and I had a bunch of
> conversations about if we thought this was worth reporting to you when we
> discovered it. Perhap
As this is fairly new stuff, and you're the one doing it: Go ahead, as you like.
Jochen
On Sun, Nov 8, 2015 at 10:05 AM, Benedikt Ritter wrote:
> Hi all,
>
> I've started work on beanutils2 again. I see a lot of potential regarding
> the API, when we upgrade the project to Java 8. For example,
On 11/07/2015 11:19 AM, Mark Thomas wrote:
> On 07/11/2015 10:13, Thomas Neidhart wrote:
>> On 11/07/2015 04:25 AM, Bernd Eckenfels wrote:
>>> Hello,
>>>
>>> I tried to raise that concern in the message already, but it is probably
>>> worth repeating it explicitly: this is not a real bug
>>> in the
Hi,
there is a lot of bad talk going on at twitter [1,2,3] and I'm wondering
whether we should respond to this via the Apache blog.
Thoughts?
Benedikt
[1] https://twitter.com/JustineTunney/status/662937508980723712
[2] https://twitter.com/kennwhite/status/662709833464872960
[3] https://twitter.c
>> Both sample payloads have "gadget chains" which do start (readObject())
>> in JCL classes and then use pretty generic interfaces like Annotations
>> or Comparators, so there is really no link between the types and the
>> specific weakness.
> I did not see JCL (commons logging?) used in the gadg
Hi all,
I've started work on beanutils2 again. I see a lot of potential regarding
the API, when we upgrade the project to Java 8. For example, I'm currently
working on an API that let's users define type conversion. It could look
like this:
import static org.apache.commons.beanutils2.ConverterBui
47 matches
Mail list logo
