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
> [1] http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/
> [2] 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-----