Details

    • Type: Sub-task
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: Release Branch 12.04, Release Branch 13.07, Release Branch 14.12, Trunk, Release Branch 15.12
    • Fix Version/s: 14.12.01, 12.04.06, 13.07.03, 15.12.01
    • Component/s: framework
    • Labels:
    • Sprint:
      Bug Crush Event - 21/2/2015

      Description

      Since it's a security fix we should also update all supported releases branches. http://groovy-lang.org/security.html

        Issue Links

          Activity

          Show
          jacques.le.roux Jacques Le Roux added a comment - See also https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-3253
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          We got issues while doing so, we are working with the (now Apache) Grooy team to fix them...

          Show
          jacques.le.roux Jacques Le Roux added a comment - We got issues while doing so, we are working with the (now Apache) Grooy team to fix them...
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          In the meantine, as described in the article above, a solution could be to fetch the code of the Groovy version we use, apply the recommended patch and use the compiled version

          Show
          jacques.le.roux Jacques Le Roux added a comment - In the meantine, as described in the article above, a solution could be to fetch the code of the Groovy version we use, apply the recommended patch and use the compiled version
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          I checked (using 7Zip) this advice from http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/#thefix

          For those faint of heart, you can be a little more surgical about it. If we examine the two exploits provided by the “ysoserial” tool, we can see that they both rely on the “InvokerTransformer” class. If we remove this class file everywhere it exists, any attempted exploits should fail. Feel free to open up your jar files with your expired copy of Winzip and delete the file at “org/apache/commons/collections/functors/InvokerTransformer.class”.

          We have no use of InvokerTransformer in our code nor the libs we use rely on it AFAIK

          Show
          jacques.le.roux Jacques Le Roux added a comment - I checked (using 7Zip) this advice from http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/#thefix For those faint of heart, you can be a little more surgical about it. If we examine the two exploits provided by the “ysoserial” tool, we can see that they both rely on the “InvokerTransformer” class. If we remove this class file everywhere it exists, any attempted exploits should fail. Feel free to open up your jar files with your expired copy of Winzip and delete the file at “org/apache/commons/collections/functors/InvokerTransformer.class”. We have no use of InvokerTransformer in our code nor the libs we use rely on it AFAIK
          Hide
          pfm.smits Pierre Smits added a comment -

          Nevertheless, maybe we should consider upgrading the various commons libraries to new versions. Some seem quite old.

          Show
          pfm.smits Pierre Smits added a comment - Nevertheless, maybe we should consider upgrading the various commons libraries to new versions. Some seem quite old.
          Hide
          jacques.le.roux Jacques Le Roux added a comment - - edited

          Thanks to Jacopo, here is the most interesting thing we know about this issue https://mail-archives.apache.org/mod_mbox/incubator-groovy-users/201509.mbox/%3C2077FA8D-553F-41B6-B344-C986E049B503@gmail.com%3E

          Since then, the Groovy team did not care much. I guess it's to us to get that done, not sure how yet...

          But because I was wrong above (OFBiz is not secure since we have an older than 2.4.4 Groovy version in the classpath which is actually enough for an exploit) and we can't let this as is until we are able to upgrade Groovy to 2.4.4 I just committed a temporary workaround fix in
          trunk r1717058+1717180
          R14.12 r1717059+1717182
          R13.07 r1717060+1717183
          R12.04 r1717061+1717184+1717185
          It should be used by anyone responsible for OFBiz security.

          Note that we are safe from an exploit done using the commons collections, see OFBIZ-6726. OFBiz does not use Spring OOTB, but if you use it you will be safe by patching with revisions above.

          Show
          jacques.le.roux Jacques Le Roux added a comment - - edited Thanks to Jacopo, here is the most interesting thing we know about this issue https://mail-archives.apache.org/mod_mbox/incubator-groovy-users/201509.mbox/%3C2077FA8D-553F-41B6-B344-C986E049B503@gmail.com%3E Since then, the Groovy team did not care much. I guess it's to us to get that done, not sure how yet... But because I was wrong above (OFBiz is not secure since we have an older than 2.4.4 Groovy version in the classpath which is actually enough for an exploit) and we can't let this as is until we are able to upgrade Groovy to 2.4.4 I just committed a temporary workaround fix in trunk r1717058+1717180 R14.12 r1717059+1717182 R13.07 r1717060+1717183 R12.04 r1717061+1717184+1717185 It should be used by anyone responsible for OFBiz security. Note that we are safe from an exploit done using the commons collections, see OFBIZ-6726 . OFBiz does not use Spring OOTB, but if you use it you will be safe by patching with revisions above.
          Hide
          jacopoc Jacopo Cappellato added a comment -

          I have upgraded the trunk and all the active release branches to Groovy 2.4.5:
          trunk: r1729609
          release branch 15.12: r1729615
          release branch 14.12: r1729623
          release branch 13.07: r1729627
          release branch 12.04: r1729630 (also removed the experimental and not used GroovyShellContainer and related classes because it was not working with the new version of Groovy)

          Show
          jacopoc Jacopo Cappellato added a comment - I have upgraded the trunk and all the active release branches to Groovy 2.4.5: trunk: r1729609 release branch 15.12: r1729615 release branch 14.12: r1729623 release branch 13.07: r1729627 release branch 12.04: r1729630 (also removed the experimental and not used GroovyShellContainer and related classes because it was not working with the new version of Groovy)
          Hide
          pfm.smits Pierre Smits added a comment -

          I guess a change of the title is in order to facilitate adopters to not have to go through the whole history of this issue.

          Show
          pfm.smits Pierre Smits added a comment - I guess a change of the title is in order to facilitate adopters to not have to go through the whole history of this issue.
          Hide
          jacopoc Jacopo Cappellato added a comment -
          Show
          jacopoc Jacopo Cappellato added a comment - I am still working on a slightly cleaner solution for the workaround mentioned in https://mail-archives.apache.org/mod_mbox/incubator-groovy-users/201509.mbox/%3C2077FA8D-553F-41B6-B344-C986E049B503@gmail.com%3E
          Hide
          jacopoc Jacopo Cappellato added a comment -

          Improved the code at revisions:
          trunk: r1729809
          15.12: r1729810
          14.12: r1729812
          13.07: r1729813
          12.04: r1729814

          Show
          jacopoc Jacopo Cappellato added a comment - Improved the code at revisions: trunk: r1729809 15.12: r1729810 14.12: r1729812 13.07: r1729813 12.04: r1729814
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          This is done

          Show
          jacques.le.roux Jacques Le Roux added a comment - This is done
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Without comment from Jose M Ledesma, I'll suspect the Untitled.workflow.zip attachment to be a dangerous spam. I see no way to remove it though.

          Show
          jacques.le.roux Jacques Le Roux added a comment - Without comment from Jose M Ledesma, I'll suspect the Untitled.workflow.zip attachment to be a dangerous spam. I see no way to remove it though.

            People

            • Assignee:
              jacopoc Jacopo Cappellato
              Reporter:
              jacques.le.roux Jacques Le Roux
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development

                  Agile