Date: Tue, 10 Nov 2015 01:10:53 +0100 From: Moritz Bechler <mbechler@...terphace.org> To: oss-security@...ts.openwall.com Subject: Re: Assign CVE for common-collections remote code execution on deserialisation flaw Am 09.11.2015 um 22:53 schrieb Tim: > >> This is not a vulnerability in the library. How can this feature allow >> remote code execution if it does not involve any networking at all? >> >> The root cause is the incorrect use of Java deserialization. As long as >> you do not fix that, something else on the classpath will serve the role >> of Apache Commons Collections. > > Can you elaborate on this last point? Can you better describe the > root cause, as you see it, and what should have been done differently > by the systems using Apache Commons? The main problem is that deserialization can easily get you into executing code paths (either through custom serialization code or other funny code). Given that the regular deserialization routines allow any (Serializable) class to be deserialized, you would have to make sure that cannot happen by any interaction of any code (what, given the sheer amount of library code in typical java projects, you simply cannot). If you cannot, you either must refrain from deserializing any untrusted or privilege-boundary-crossing data or use a whitelisting approach to reduce the amount of classes you need to check for problems (that of course still leaves room for error and often is not easily possible as the code performing the deserialization is buried in libraries or even the standard library). Regarding the issue at hand, it's pretty clear that the involved parties make different assumptions about whether it should be okay to deserialize untrusted data and there simply is no way of differentiating between the two - one Serializable to rule them all. (Standard library behaviour, OpenJDK, is also a bit frightening, as they, for example, assume it is okay to call into collection api methods). Given that, the only sane advice I have right now is - don't do it at all. No RMI, JMX, whatever. Of course that is pretty inconvenient. This needs to be fixed on a much lower level than commons collections. Whitelisting might be a mitigation, but right now, e.g. for RMI code you cannot really do it without patching your JRE. Moritz
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ