commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <ja...@carmanconsulting.com>
Subject Re: [collection][security] InvokerTransformer missused in java object serialisation exploits
Date Sun, 08 Nov 2015 19:17:04 GMT
Yes, I guess it should be prevented. Duh!
On Sun, Nov 8, 2015 at 2:16 PM Mark Thomas <markt@apache.org> 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
> property is set such that this attack is blocked, they can't use the
> attack to change the system property and unblock it.
>
> Mark
>
>
> > On Sun, Nov 8, 2015 at 2:11 PM James Carman <james@carmanconsulting.com>
> > wrote:
> >
> >> System.setProperty()
> >>
> >>
> >> On Sun, Nov 8, 2015 at 2:10 PM Thomas Neidhart <
> thomas.neidhart@gmail.com>
> >> 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-serialized class.
> >>> Right now, the simplest way to do so is via the InvokerTransformer.
> >>>
> >>> There are surely other ways to do so, but if the only available way is
> >>> blocked (i.e. InvokerTransformer can not be deserialized), a remote
> >>> attacker cannot set a system property via this attack vector.
> >>>
> >>> btw. setting a system property can also be restricted by a
> >>> SecurityManager.
> >>>
> >>> I am -1 on a programmatic interface, and for the 4.X branch I propose
> to
> >>> remove the serialization support completely.
> >>>
> >>> Thomas
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message