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. Other ways to fix this issue seem to be quite complex, i.e. change the way serialization is performed (use whitelisting, ...), and will most likely not be executed in a timely manner. I wonder if some people already ship a collections version with this class being removed/manipulated, or use a runtime weaving technique to remove the serialization support from it? Setting up a reasonable security policy for this line of attack also seems to be futile as it would have to be so restrictive that most applications probably wont work anymore. > So it seems to be a good idea to discuss some hardening. Unfortunatelly > having a hardened distribution with only this one class removed might > be a bit overkill. Are there other candidates to be left out in such a > more specific distribution? Maybe everything proxy/reflection related? I checked the codebase, and there are other Invoker* type classes but they all use internally the InvokerTransformer. > 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 gadget chains. btw. the technique using the TransformerImpl from xalan (which is part of the oracle/openjdk jre) is really scary as it allows an attacker to inject arbitrary bytecode. Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
