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 InvokerTransformer, he or she gets a clear
and loud exception, that advices what to do (set the property). Should
be a solution that makes everyone happy in the medium term.
Jochen
On Sun, Nov 8, 2015 at 3:30 PM, sebb <seb...@gmail.com> wrote:
> On 8 November 2015 at 12:32, Mark Thomas <ma...@apache.org> 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 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 in the talk and even here on Twitter:
>>>>>>
>>>>>> https://twitter.com/gebl/status/662754611304996866
>>>>>>
>>>>>> however, as the "foxglove" article shows, people still point at the
>>>>>> apache project, and after all it is good pratice to reduce footprints
>>>>>> and attack surfaces.
>>>>>
>>>>> it is clear that the InvokerTransformer by itself does not have a bug,
>>>>> but due to the way how java serialization is applied and considering the
>>>>> fact that at least collections-3.2.1 is used *a lot* it would make sense
>>>>> to provide a hardened version of collections to give people a chance to
>>>>> easily avoid this line of attack in their application.
>>>>>
>>>>> Instead of removing the class we could prevent de-serialization of it in
>>>>> the hardened jar. This would not break b/c and it is very unlikely that
>>>>> the InvokerTransformer is serialized in legit ways.
>>>>
>>>> Rather than having hardened vs unhardened JARs, it would probably be
>>>> better to use a system property to enable/disable the behaviour. I don't
>>>> know the code or the vulnerability well enough to know exactly where to
>>>> put this switch so it prevents the attack but has minimal impact on
>>>> other uses.
>>>
>>> my idea was to have a binary compatible drop-in replacement that does
>>> not require any configuration, so that people that happen to have
>>> commons-collections 3.2.1 in their classpath can replace it with a
>>> hardened version.
>>>
>>> But I am open to other suggestions, in the end it is important to do
>>> what affected users would like to have to mitigate the problem.
>>
>> My main concern with a hardened JAR is that, while with just this
>> vulnerability, we end up with two JARs but how many JARs will we end up
>> with 3 or 4 vulnerabilities down the line. Particularly when fixing a
>> vulnerability means breaking functionality. I think system properties
>> scale better.
>
> But is there a use case for partially hardened jars?
> Surely if there are additional vulnerabilities they need to be fixed as well?
>
> Using system properties simpifies things for Commons developers,
> however it makes it harder for consumers, as they have to ensure that
> the property is set.
> This may be hard to check if the jar is part of a large system.
>
> Though it would allow for certain vulnerabilities to be disabled by
> default (i.e.one has set a property to enable the risky code - [*])
> and others only on demand.
>
> [*] This approach is already taken by the JDK with
> sun.net.http.allowRestrictedHeaders
> See: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6996110
>
>> Mark
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
--
The next time you hear: "Don't reinvent the wheel!"
http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
