[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20151117224128.B300342E101@smtpvbsrv1.mitre.org>
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-----
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
