oss-sec mailing list archives
Re: Assign CVE for common-collections remote code execution on deserialisation flaw
From: Moritz Bechler <mbechler () eenterphace org>
Date: Tue, 10 Nov 2015 01:10:53 +0100
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
Current thread:
- Assign CVE for common-collections remote code execution on deserialisation flaw Jason Shepherd (Nov 08)
- Re: Assign CVE for common-collections remote code execution on deserialisation flaw Florian Weimer (Nov 08)
- Re: Assign CVE for common-collections remote code execution on deserialisation flaw Pedro Vaz De Sousa Grilo (Nov 09)
- Re: Assign CVE for common-collections remote code execution on deserialisation flaw Tim (Nov 09)
- Re: Assign CVE for common-collections remote code execution on deserialisation flaw Moritz Bechler (Nov 09)
- Re: Assign CVE for common-collections remote code execution on deserialisation flaw Tim (Nov 10)
- Re: Assign CVE for common-collections remote code execution on deserialisation flaw Moritz Bechler (Nov 11)
- Re: Assign CVE for common-collections remote code execution on deserialisation flaw Tim (Nov 11)
- CVE-Request: Assign CVE for common-collections remote code execution on deserialisation flaw Gsunde Orangen (Nov 12)
- Re: CVE-Request: Assign CVE for common-collections remote code execution on deserialisation flaw Mark Felder (Nov 12)
- Re: CVE-Request: Assign CVE for common-collections remote code execution on deserialisation flaw Tim (Nov 12)
- Re: CVE-Request: Assign CVE for common-collections remote code execution on deserialisation flaw Mark Felder (Nov 13)
- Re: CVE-Request: Assign CVE for common-collections remote code execution on deserialisation flaw Tim (Nov 13)
- Re: CVE-Request: Assign CVE for common-collections remote code execution on deserialisation flaw Gsunde Orangen (Nov 12)
- Re: CVE-Request: Assign CVE for common-collections remote code execution on deserialisation flaw Mark Felder (Nov 13)
- Re: Assign CVE for common-collections remote code execution on deserialisation flaw Florian Weimer (Nov 08)