Date: Wed, 6 Jun 2018 13:33:59 +0200 From: Tomas Hoger <thoger@...hat.com> To: Denis Magda <dmagda@...che.org> Cc: oss-security@...ts.openwall.com, dev <dev@...ite.apache.org>, "Rai, Harendra" <harendra.rai@....com> Subject: Re: [CVE-2014-0114]: Apache Ignite is vulnerable to existing CVE-2014-0114 Hi Denis! On Fri, 1 Jun 2018 10:16:50 -0700 Denis Magda wrote: > [CVE-2014-0114]: Apache Ignite is vulnerable to existing CVE-2014-0114 > > Severity: Important > > Vendor: The Apache Software Foundation > > Versions Affected: Apache Ignite 2.4 or earlier > > Impact: > An attacker can execute arbitrary code on Ignite nodes in the case > when Ignite classpath contains arbitrary vulnerable classes. > > Description: > Apache Ignite used commons-beanutils-1.8.3.jar library which did not > suppress the class property, which allowed 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. This announcement is very light on details. Would it be possible to provide more details, ideally a link to the fix that was applied to address this issue? Searching for more information, I found out that the upstream Jira ticket for this issue should be: https://issues.apache.org/jira/browse/IGNITE-8472 The ticket is non-public, but its content is leaked via a mailing list: https://www.mail-archive.com/search?l=issues%40ignite.apache.org&q=subject%3AIGNITE-8472 This has some important info, indicating that the problem (only?) affects Ignite for .NET. The reported problem basically seems to be: Ignite for .NET bundles commons-beanutils 1.8.3 and that should be upgraded to 1.9.2. Looking into apache.ignite.2.4.0.nupkg and apache.ignite.2.5.0.nupkg, I can see that commons-beanutils upgrade as requested did happen in 2.5.0. Note that I do not see any commons-beanutils jar in apache-ignite-fabric-2.4.0-bin.zip and apache-ignite-fabric-2.5.0-bin.zip. Are those, as well as source distribution, considered unaffected? Now back to the CVE - I do not believe that your re-use of the old CVE-2014-0114 is correct. In the report, there was some ambiguity whether Struts or Commons-BeanUtils should be blamed for the flaw, however it seems to be explicit enough that the CVE-2014-0114 is for Struts: http://openwall.com/lists/oss-security/2014/06/15/10 As noted in the mail, the problem wasn't fixed in Commons-BeanUtils, which only added mechanisms to make it easy for applications using Commons-BeanUtils to easily disable processing of the "class" property. It did not even disable processing by default, as noted in the release notes: http://commons.apache.org/proper/commons-beanutils/javadocs/v1.9.2/RELEASE-NOTES.txt """ Release 1.9.2 mainly addresses a potential security issue when accessing properties in an uncontrolled way. In a nutshell, if an application that uses Commons BeanUtils passes property paths from an external source directly to the getProperty() method of BeanUtilsBean, an attacker can access the class loader via the class property available on all Java objects. In version 1.9.2 now a special BeanIntrospector class was added which allows suppressing this property. Note that this BeanIntrospector is NOT enabled by default! Commons BeanUtils is a low-level library, and on this layer it cannot be decided whether access to a certain property is legal or not. Therefore, an application has to activate this suppressing BeanIntrospector explicitly. This can be done with the following lines of code: BeanUtilsBean bub = new BeanUtilsBean(); bub.getPropertyUtils().addBeanIntrospector( SuppressPropertiesBeanIntrospector.SUPPRESS_CLASS); Now all access to properties has to be done via the specially configured BeanUtilsBean instance. More information about this issue can be found at https://issues.apache.org/jira/browse/BEANUTILS-463 or in section 2.5 of the user's guide. """ Note that there was a request to assign a separate CVE for the BeanUtils part that was rejected (actually, CVE-2014-3540 was assigned and later rejected), see this post from Mitre for details: http://openwall.com/lists/oss-security/2014/07/08/1 It has few parts that are relevant to Ignite: """ 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. """ Did Ignite get any other changes related to this issue apart from upgrading Commons-BeanUtils? If not, Commons-BeanUtils upgrade should not be expected to solve the problem (if Ignite actually was affected / used Commons-BeanUtils in a vulnerable way, which isn't demonstrated in the IGNITE-8472). Another relevant part is: """ If any other product makes a security announcement that they have added addBeanIntrospector(SuppressPropertiesBeanIntrospector.SUPPRESS_CLASS) 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. """ If Ignite got/gets a fix that leverages the SUPPRESS_CLASS from Commons-BeanUtils 1.9.2 to disable processing of the class property, it should get its own CVE assigned. -- Tomas Hoger / Red Hat Product Security
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.