Uploaded image for project: 'Velocity'
  1. Velocity
  2. VELOCITY-869

Vulnerability in dependency: commons-collections:3.2.1

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.7
    • Fix Version/s: 1.x, 2.0
    • Component/s: Build
    • Labels:
      None

      Description

      There is an arbitrary remote code execution bug in commons-collections, tracked by COLLECTIONS-580. Updating to the version where this bug is fixed, 3.2.2, will help downstream libraries (like avro-ipc) from pulling in the bad version. Thanks!

        Issue Links

          Activity

          Hide
          sdumitriu Sergiu Dumitriu added a comment -

          Committed, thanks for reporting it.

          Show
          sdumitriu Sergiu Dumitriu added a comment - Committed, thanks for reporting it.
          Hide
          bmartin Brian Martin added a comment -

          Please note that Commons Collections is designed to deserialize code. The "fix" is to add an option to disable that, which each implementing software needs to consider. Further, just having Commons Collections in your software does not necessarily mean you are, or are not, vulnerable. Each application must assess if they allow users to send code to be deserialized to that library (its intended function), and if that crosses privilege boundaries are not.

          So just upgrading to 3.2.2 doesn't mean you are necessarily fixing a vuln, and the presence of that software doesn't necessarily mean you were vulnerable in the first place. =)

          Show
          bmartin Brian Martin added a comment - Please note that Commons Collections is designed to deserialize code. The "fix" is to add an option to disable that, which each implementing software needs to consider. Further, just having Commons Collections in your software does not necessarily mean you are, or are not, vulnerable. Each application must assess if they allow users to send code to be deserialized to that library (its intended function), and if that crosses privilege boundaries are not. So just upgrading to 3.2.2 doesn't mean you are necessarily fixing a vuln, and the presence of that software doesn't necessarily mean you were vulnerable in the first place. =)
          Hide
          yoderme Mike Yoder added a comment -

          All true. However, in some sense what you say almost does not matter. There are many corporate security departments that are going to raise red flags about the presence of this library in the classpath. Explaining to them why you think you're not vulnerable may or may not work, and it's hard to prove a negative. In my experience it's easiest to just do the upgrade.

          Show
          yoderme Mike Yoder added a comment - All true. However, in some sense what you say almost does not matter. There are many corporate security departments that are going to raise red flags about the presence of this library in the classpath. Explaining to them why you think you're not vulnerable may or may not work, and it's hard to prove a negative. In my experience it's easiest to just do the upgrade.
          Hide
          bmartin Brian Martin added a comment -


          Absolutely, and I encourage vendors to upgrade libraries as a precaution. I point it out because that even in upgrading to a new version, an application may still be vulnerable. Ideally, I want vendors to upgrade and positively confirm if they were vulnerable to begin with, and if the upgrade also includes configuration changes to remove the issue.

          Show
          bmartin Brian Martin added a comment - Absolutely, and I encourage vendors to upgrade libraries as a precaution. I point it out because that even in upgrading to a new version, an application may still be vulnerable. Ideally, I want vendors to upgrade and positively confirm if they were vulnerable to begin with, and if the upgrade also includes configuration changes to remove the issue.
          Hide
          yoderme Mike Yoder added a comment -

          Agreed completely. This vulnerability (and this entire class of vulnerability) is going to be afflicting large swaths of the open source community for some time...

          Show
          yoderme Mike Yoder added a comment - Agreed completely. This vulnerability (and this entire class of vulnerability) is going to be afflicting large swaths of the open source community for some time...
          Hide
          sdumitriu Sergiu Dumitriu added a comment -

          The only two classes used from commons-collections are ExtendedProperties and LRUMap, so I would say that Velocity wasn't affected before, and still isn't affected.

          Show
          sdumitriu Sergiu Dumitriu added a comment - The only two classes used from commons-collections are ExtendedProperties and LRUMap , so I would say that Velocity wasn't affected before, and still isn't affected.
          Hide
          rdblue Ryan Blue added a comment -

          Great, it sounds like Velocity's use wasn't a risk. But the way dependencies are handled in Java could easily mean that 3.2.1 gets included in the classpath and used instead of 3.2.2 in an application that would be vulnerable.

          Show
          rdblue Ryan Blue added a comment - Great, it sounds like Velocity's use wasn't a risk. But the way dependencies are handled in Java could easily mean that 3.2.1 gets included in the classpath and used instead of 3.2.2 in an application that would be vulnerable.
          Hide
          marks Mark Symons added a comment - - edited

          Linked to VELTOOLS-169, as Velocity Tools pulls in Velocity as a compile dependency.

          I am delighted to read here that Velocity was not actually at risk but did arrive at this issue from the starting point of performing a security audit. I totally agree with the previous comments that it can be very hard to work with automatically generated reports and then have to annotate umpteen items to explain why they do not matter.

          it's easiest to just do the upgrade

          Yup!

          Show
          marks Mark Symons added a comment - - edited Linked to VELTOOLS-169 , as Velocity Tools pulls in Velocity as a compile dependency. I am delighted to read here that Velocity was not actually at risk but did arrive at this issue from the starting point of performing a security audit. I totally agree with the previous comments that it can be very hard to work with automatically generated reports and then have to annotate umpteen items to explain why they do not matter. it's easiest to just do the upgrade Yup!
          Hide
          tim@vertein.com Timothy A Vertein added a comment -

          Late to the audit party, but also using Velocity in my project. Was there a patch release? Maybe 1.7.1 that I could use? I couldn't find any new releases.

          Thanks!

          Show
          tim@vertein.com Timothy A Vertein added a comment - Late to the audit party, but also using Velocity in my project. Was there a patch release? Maybe 1.7.1 that I could use? I couldn't find any new releases. Thanks!
          Hide
          nimg87 Nimisha Gupta added a comment -

          Sergiu Dumitriu

          Hi, I am using Velocity 1.7.However, I need to get rid of commons-collections 3.2.1 vulnerability.It seems that you have resolved this issue in version 1.7.1/2.x. These versions are not yet released, is there a specific release date or alternative through which I can get rid of this vulnerability?

          Thanks!

          Show
          nimg87 Nimisha Gupta added a comment - Sergiu Dumitriu Hi, I am using Velocity 1.7.However, I need to get rid of commons-collections 3.2.1 vulnerability.It seems that you have resolved this issue in version 1.7.1/2.x. These versions are not yet released, is there a specific release date or alternative through which I can get rid of this vulnerability? Thanks!
          Hide
          sdumitriu Sergiu Dumitriu added a comment -

          There are no real code changes, so all you have to do is replace one jar with the other in your project.

          Show
          sdumitriu Sergiu Dumitriu added a comment - There are no real code changes, so all you have to do is replace one jar with the other in your project.
          Hide
          nimg87 Nimisha Gupta added a comment -

          Sergiu Dumitriu

          That would mean excluding commons-collections 3.2.1 and explicitly include commons-collections 3.2.2?

          Thanks in advance!

          Show
          nimg87 Nimisha Gupta added a comment - Sergiu Dumitriu That would mean excluding commons-collections 3.2.1 and explicitly include commons-collections 3.2.2? Thanks in advance!
          Hide
          sdumitriu Sergiu Dumitriu added a comment -

          Depends on how your build works. If you're using Maven, you can either add a <dependency> on commons-collections 3.2.2 (no need to exclude 3.2.1, Maven automatically selects just one version for a library), or add a <dependencyManagement><dependencies><dependency> on 3.2.2, which will make Maven automatically upgrade the transitive dependency, without declaring a dependency that's not actually used by your code.

          Show
          sdumitriu Sergiu Dumitriu added a comment - Depends on how your build works. If you're using Maven, you can either add a <dependency> on commons-collections 3.2.2 (no need to exclude 3.2.1, Maven automatically selects just one version for a library), or add a <dependencyManagement><dependencies><dependency> on 3.2.2, which will make Maven automatically upgrade the transitive dependency, without declaring a dependency that's not actually used by your code.
          Hide
          marks Mark Symons added a comment -

          No matter how straight-forward to It may be tweak the transitive dependency, there is an aversion by some to doing this rather than getting an updated version of velocity that includes the fix outright.

          This issue was resolved a year ago and still has not been released.

          Would it not be possible to actually get this pushed out the door?

          I see that v1.x has only 1 outstanding planned issue (out of 8).

          VELOCITY-862: Applied to 1.x branch and Resolved... and then "Reopening at Nathan's suggestion that we may want to apply this to 2.x"

          Velocity 2.x also has only 1 outstanding planned issue (out of 118):

          VELOCITY-876

          Both VELOCITY-862 and VELOCITY-876 are improvements, not defects.

          There is another reason to release Velocity... v1.7 is now giving alerts in scanning software due to age... "architectural age" policy in Sonatype Nexus IQ and (from memory) "Operational Risk" in Black Duck Hub. Such alerts are more than enough on their own to cause some managers to issue instructions to remove Velocity entirely.

          All the above for Velocity also applies to Velocity Tools.

          Perhaps connected to all of the above... does this JIRA project still have an active project lead? Will Glass-Husain's last activity stream entry is from 2014.

          Show
          marks Mark Symons added a comment - No matter how straight-forward to It may be tweak the transitive dependency, there is an aversion by some to doing this rather than getting an updated version of velocity that includes the fix outright. This issue was resolved a year ago and still has not been released. Would it not be possible to actually get this pushed out the door? I see that v1.x has only 1 outstanding planned issue (out of 8). VELOCITY-862 : Applied to 1.x branch and Resolved... and then "Reopening at Nathan's suggestion that we may want to apply this to 2.x" Velocity 2.x also has only 1 outstanding planned issue (out of 118): VELOCITY-876 Both VELOCITY-862 and VELOCITY-876 are improvements, not defects. There is another reason to release Velocity... v1.7 is now giving alerts in scanning software due to age... "architectural age" policy in Sonatype Nexus IQ and (from memory) "Operational Risk" in Black Duck Hub. Such alerts are more than enough on their own to cause some managers to issue instructions to remove Velocity entirely. All the above for Velocity also applies to Velocity Tools. Perhaps connected to all of the above... does this JIRA project still have an active project lead? Will Glass-Husain's last activity stream entry is from 2014.
          Hide
          claude Claude Brisson added a comment -

          There probably won't be any more 1.x release, but the 2.0 should not take long, now.

          Show
          claude Claude Brisson added a comment - There probably won't be any more 1.x release, but the 2.0 should not take long, now.

            People

            • Assignee:
              sdumitriu Sergiu Dumitriu
              Reporter:
              rdblue Ryan Blue
            • Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development