Date: Tue, 17 Nov 2015 17:41:28 -0500 (EST) From: cve-assign@...re.org To: oss-security@...ts.openwall.com Cc: cve-assign@...re.org Subject: Re: Assign CVE for common-collections remote code execution on deserialisation flaw -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >  http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/ >  https://issues.apache.org/jira/browse/COLLECTIONS-580 The MITRE CVE team has no current plans to provide a CVE ID associated with the Apache Commons Collection product for its behavior described at: https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread and elsewhere. Our interpretation is that some people are taking a position that, very roughly, corresponds to: - suppose that a library product is very difficult to deploy safely in a use case involving untrusted input - furthermore, suppose that part of this library product has semantics that are inconsistent with the usual semantics for the programming language in use - furthermore, suppose that a number of applications are actually using this library in a very unsafe way - furthermore, suppose that the vendor of this library product has decided to change this product's behavior so that (among other differences) it will sometimes be easier to deploy safely - furthermore, suppose that this vendor's change notification seems to be more about hardening the library as a way to help prevent exploitation of current or future applications, and seems to be less about announcing the original behavior as a library vulnerability - still, a CVE ID could be used as a name for the original behavior We prefer not to have a CVE ID for the library product in this situation. There is a continuum between "inadvertent coding error" on the left side and "a choice that was reasonable for a smaller than expected fraction of customers" on the right side. The situation here is not far enough to the left to have a CVE ID. The CVE-2015-3253 ID came from the Apache Software Foundation itself, and thus can't be generalized to other cases that may seem similar. The CVE-2015-4852 ID came from Oracle and must remain associated only with Oracle's own software (WebLogic Server is the product they've named). We'll send a separate response about the Jenkins SECURITY-218 report. - -- CVE assignment team, MITRE CVE Numbering Authority M/S M300 202 Burlington Road, Bedford, MA 01730 USA [ PGP key available through http://cve.mitre.org/cve/request_id.html ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJWS6xKAAoJEL54rhJi8gl5QJ0P/11kaNbWjxC2RpWh4L8Y1U29 Jo+LSwxdBDmh8v8I0Xab4ne6/rmqKN7iPl65yy7J7t8ULYcf2fcU4lUe93sZHpk9 hPWX/x4eYQBQRS89f7lerYD/RK0hTJ8RGQIsfqYCScEmFuNpqdOA0LoXhGCJFu7p 63GRtyJuvI0sZkFQKYY5l9A8E2fDLMHyEk9NWyTgwWNKXZWVyMQAkXipbtVko/xy DjtVA0OTgaje0PZzh6moFU1rwwMqkSmq+5pXPpUq+iCrAP55RIuEFzzM+sBhgeEG 6I9JoEjaGci+w6t+jnEwLfzjFWDL9ioFkenyqG0GsTdd7fGC96Lsa2jHI7ZsDy6g 4GLTUJ/BEhQxKNvQ88cNfUNsyIP8NzLdwjChvxEa7m4CmnxmHU++MQZXmlo8Aq6C PBLrWeKaOGhGz6fs8H0NNWfcM5GAco6nEK8d4EYLsb7lIVNrGqaNpwKqnkfntK97 9vH7OnrIAIfnneyKH8+53IcN1ogPrBmwLPY9DDTU2XUIOlWE7IvtRtmpuBX884KF 7c5r2pA/xgecczvjGQ5C9t0yMzrNgPBNgfkG9RsPnh/1LOhcm/tA4Ijo21JXmYb6 2s6MF3yl9H8qvtRAu1fMCUMjuHa4wTOH7Uv57MeJsFVzRZvNxf0nmlWRV5PrLGuW VHHOmkmQRl9UWJ9jGv14 =93c8 -----END PGP SIGNATURE-----
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