Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 7 Jul 2014 22:20:19 -0400 (EDT)
Subject: Re: CVE request for commons-beanutils: 'class' property is exposed, potentially leading to RCE

Hash: SHA1


> "A specialized BeanIntrospector implementation has been added which
> allows suppressing properties. There is also a pre-configured instance
> removing the class property from beans. Some notes have been added to
> the user's guide."
> I think it would be appropriate to assign a CVE ID to this issue

As far as we can tell, these are the specific commons-beanutils changes
for which you proposed to have a CVE ID:

   Because the class property is undesired in many use cases there is
   already an instance of SuppressPropertiesBeanIntrospector which is
   configured to suppress this property.

   public static final SuppressPropertiesBeanIntrospector SUPPRESS_CLASS =
   new SuppressPropertiesBeanIntrospector(Collections.singleton("class"));

   public class SuppressPropertiesBeanIntrospector implements BeanIntrospector

(Note that the last version of Apache Struts 1, version 1.3.10,
bundles commons-beanutils-1.8.0.jar in its lib directory. The 1.8.0
codebase obviously does not have the recently introduced
SuppressPropertiesBeanIntrospector class. To the extent that "The root
cause of this [CVE-2014-0114] flaw is that commons-beanutils exposes
the class property by default," we have a situation with the same
problem in two copies of the same original codebase, i.e., the copy
bundled in from and the copy found at the
URL. In this context, the same problem cannot be represented by two
different CVE IDs.)

The entire set of changes from the above URLs
makes it easier to use commons-beanutils safely, but it does not
change the default configuration or behavior in any way, and is thus
not eligible for a CVE ID.

In particular, the 1597344 change has this documentation:

   Adding this instance as BeanIntrospector to an instance of
   PropertyUtilsBean suppresses the class property; it can then no
   longer be accessed.

This is an additional step that would need to be followed for any
currently shipped product that relies on commons-beanutils. Simply
picking up version 1.9.2 does not solve the problem. The product's
source code must additionally be modified by (for example) changing
or adding an addBeanIntrospector method call.

Points that you raise, such as:

 - This would provide framework developers with the necessary
   information and impetus to upgrade

 - The commons-beanutils patch could be inherited by other frameworks
   that may not have the resources to produce their own patch

are worthwhile, but the scope of the CVE project does not include
IDs that exist only for a communication/outreach goal.

We are proceeding in this way:

  - immediately REJECT CVE-2014-3540 because, at the level of
    abstraction used by CVE, a second CVE ID is not required

  - at the same time, change the CVE-2014-0114 description and
    references to emphasize your important finding about the root
    cause. For example, the new CVE-2014-0114 description may be
    similar to:

    Apache Commons BeanUtils, as distributed in
    lib/commons-beanutils-1.8.0.jar in Apache Struts 1.x through
    1.3.10 and in other products requiring commons-beanutils through
    1.9.2, does not suppress the class property, which allows remote
    attackers to "manipulate" the ClassLoader and execute arbitrary
    code via the class parameter, as demonstrated by the passing of
    this parameter to the getClass method of the ActionForm object in
    Struts 1.

If any other product makes a security announcement that they have
or equivalent code as a change to the default behavior, then there can
be an individual CVE ID for that product. However, if any other product
simply makes a security announcement that they have decided to ship
commons-beanutils 1.9.2 -- but the class property remains exposed in
the product as it is shipped and installed by default -- then a CVE ID
would not be assigned.

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through ]
Version: GnuPG v1.4.14 (SunOS)


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.