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
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
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
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
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
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
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 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 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
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
>> 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
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. Perhaps we made the wrong decision, hard to say. We don't
think
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 Commons-Collection class, and it might not be wors
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 Commons-Collection class, and it might not be worse fixing it, as
> there are possibly tons of other
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 Commons-Collection class, and it might not be worse fixing it, as
there are possibly tons of other vectors. This was also addressed by the
original authors i
On 11/07/2015 12:56 AM, Thomas Neidhart wrote:
> On 11/06/2015 10:25 PM, Bernd Eckenfels wrote:
>> ello,
>>
>> I came across this article:
>>
>> http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/
>>
>> It d
On 11/06/2015 10:25 PM, Bernd Eckenfels wrote:
> ello,
>
> I came across this article:
>
> http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/
>
> It describes attacks against common Java applications wit
ello,
I came across this article:
http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/
It describes attacks against common Java applications with
pre-authentication requests using malicious Java Object ser
33 matches
Mail list logo
