Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ