Community
Participate
Working Groups
Hello Dali team, There has been a recent discovery of high severity security vulnerability in Apache org.apache.commons.collections.jar. It is learned that an attacker can inject code using serialization/deserialization techniques and expose customers information. Here are few links that discuss about this vulnerability in detail: http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/ https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread https://issues.apache.org/jira/browse/COLLECTIONS-580 Apache knows about the problem and working on a fix (link 3). They will be including the fix in 3.2.2 version. I have opened a bug with Orbit to pick up the jar containing the fix as soon as the fix is available. https://bugs.eclipse.org/bugs/show_bug.cgi?id=482130 This defect is to address necessary changes required in our code. I found the reference to the above jar at following locations: 1. /org.eclipse.jpt.jpa.gen/META-INF/MANIFEST.MF org.apache.commons.collections;bundle-version="[3.2.0,4.0.0)", Apache org.apache.commons.collections.jar security vulnerability 2. org.eclipse.jpt.jpa.feature/feature.xml <plugin id="org.apache.commons.collections" download-size="0" install-size="0" version="3.2.0.qualifier" unpack="false"/> 3. org.eclipse.jpt.jpa.feature/pom.xml Thanks Vaninder
Thanks for putting this together. From the description and sound of things, it looks like this should be a no-op for Dali as our version range should handle the new jar. I suspect we will want to put this in Mars.2 and Neon.
Please note that per Apache, the 'fix' is to add a feature that allows a developer to disable the deserialization essentially. The presence of Commons Collections alone may not indicate a vulnerability. Has anyone determined if there is a path for an unprivileged user to reach a script or interface that allows deserialization, which would be an issue?
(In reply to Brian Martin from comment #2) > Please note that per Apache, the 'fix' is to add a feature that allows a > developer to disable the deserialization essentially. The presence of > Commons Collections alone may not indicate a vulnerability. Has anyone > determined if there is a path for an unprivileged user to reach a script or > interface that allows deserialization, which would be an issue? As far as I understand the fix, the deserialization is disabled by default and you have to enable it using a switch. https://commons.apache.org/proper/commons-collections/release_3_2_2.html
Hello Neil, The build just failed after picking up the 3.2.2 version of org.apache.commons.collection.jar. Here is the error: [ERROR] Missing requirement: org.eclipse.jpt.jpa.feature.feature.group 3.4.2.qualifier requires 'org.apache.commons.collections [3.2.0,3.2.1)' but it could not be found Thanks
(In reply to Vaninder Rajput from comment #4) It looks like we need to fix the commons.collections reference in our jpt.jpa feature definition. We shouldn't be specifying a fixed version here. Brian is going to take a look.
(In reply to Neil Hauge from comment #5) > (In reply to Vaninder Rajput from comment #4) > ... We shouldn't be specifying a fixed version here. Actually, I think you'd want to (at least) use 3.2.2 as the minimum, just to make sure you get (or run with) the fixed version.
(In reply to David Williams from comment #6) > (In reply to Neil Hauge from comment #5) > > (In reply to Vaninder Rajput from comment #4) > > ... We shouldn't be specifying a fixed version here. > > Actually, I think you'd want to (at least) use 3.2.2 as the > minimum, just to make sure you get (or run with) the fixed version. David, this is a version specified in a feature.xml, not a version specified in a MANIFEST.MF; so no range is specified. Currently, it looks like this: <plugin id="org.apache.commons.collections" download-size="0" install-size="0" version="3.2.0.qualifier" unpack="false"/> Do I simply change the version to "3.2.2.qualifier"? Or is "0.0.0" more appropriate? Since the manifests can check the version. Currently, the manifests looks like this: org.apache.commons.collections;bundle-version="[3.2.0,4.0.0)" Which should be OK with the new version.
(In reply to Brian Vosburgh from comment #7) > (In reply to David Williams from comment #6) > > (In reply to Neil Hauge from comment #5) > > > (In reply to Vaninder Rajput from comment #4) > > > ... We shouldn't be specifying a fixed version here. > > > > Actually, I think you'd want to (at least) use 3.2.2 as the > > minimum, just to make sure you get (or run with) the fixed version. > > David, > this is a version specified in a feature.xml, not a version specified in a > MANIFEST.MF; so no range is specified. > > Currently, it looks like this: > > <plugin > id="org.apache.commons.collections" > download-size="0" > install-size="0" > version="3.2.0.qualifier" > unpack="false"/> > > Do I simply change the version to "3.2.2.qualifier"? > > Or is "0.0.0" more appropriate? Since the manifests can check the version. > > Currently, the manifests looks like this: > > org.apache.commons.collections;bundle-version="[3.2.0,4.0.0)" > > Which should be OK with the new version. Is there a plugin that has this listed in its manifest.mf? That is, has a dependency on it? If not ... I'd be curious to how it's used. But, admit there could be funny ways it's "discovered" ... which makes it sort of optional? In any case, 3.2.2 minimum would be good there, in plugin manifest, so I'd suggest you also use 3.2.2 in your feature. This would mostly be "for safety" in case you or others happened to be doing a build and 3.2.0 just happened to be available in some old repository somewhere, then you using a minimum of 3.2.2 would make sure it was not accidentally pulled in. HTH
> Is there a plugin that has this listed in its manifest.mf? That is, > has a dependency on it? If not ... I'd be curious to how it's used. But, > admit there could be funny ways it's "discovered" ... which makes it sort of > optional? > > In any case, 3.2.2 minimum would be good there, in plugin manifest, so I'd > suggest you also use 3.2.2 in your feature. This would mostly be "for > safety" in case you or others happened to be doing a build and 3.2.0 just > happened to be available in some old repository somewhere, then you using a > minimum of 3.2.2 would make sure it was not accidentally pulled in. When you have a bit more time, could you re-read my comment 7? I don't think you answered my questions. :-)
(In reply to Brian Vosburgh from comment #9) > > Is there a plugin that has this listed in its manifest.mf? That is, > > has a dependency on it? If not ... I'd be curious to how it's used. But, > > admit there could be funny ways it's "discovered" ... which makes it sort of > > optional? > > > > In any case, 3.2.2 minimum would be good there, in plugin manifest, so I'd > > suggest you also use 3.2.2 in your feature. This would mostly be "for > > safety" in case you or others happened to be doing a build and 3.2.0 just > > happened to be available in some old repository somewhere, then you using a > > minimum of 3.2.2 would make sure it was not accidentally pulled in. > > When you have a bit more time, could you re-read my comment 7? I don't think > you answered my questions. :-) This one? > Or is "0.0.0" more appropriate? The answer is "no". That is only appropriate if you are positive there is only "one version" that you could possibly "get" during your build. Primarily your own stuff ... or, if you "don't really care" which version you get ... or if you are positive all your MANIFEST.MF files in all your plugins correctly specify the versions you care about. So, I was just thinking it is safest to use 3.2.2.qualifier, since this is a case you care about making sure you get the right one. Let me know if I still missed your main question.
(In reply to David Williams from comment #10) > (In reply to Brian Vosburgh from comment #9) > > > Is there a plugin that has this listed in its manifest.mf? That is, > > > has a dependency on it? If not ... I'd be curious to how it's used. But, > > > admit there could be funny ways it's "discovered" ... which makes it sort of > > > optional? > > > > > > In any case, 3.2.2 minimum would be good there, in plugin manifest, so I'd > > > suggest you also use 3.2.2 in your feature. This would mostly be "for > > > safety" in case you or others happened to be doing a build and 3.2.0 just > > > happened to be available in some old repository somewhere, then you using a > > > minimum of 3.2.2 would make sure it was not accidentally pulled in. > > > > When you have a bit more time, could you re-read my comment 7? I don't think > > you answered my questions. :-) > > This one? > > Or is "0.0.0" more appropriate? > > The answer is "no". That is only appropriate if you are positive there is > only "one version" that you could possibly "get" during your build. > Primarily your own stuff ... or, if you "don't really care" which version > you get ... or if you are positive all your MANIFEST.MF files in all your > plugins correctly specify the versions you care about. So, I was just > thinking it is safest to use 3.2.2.qualifier, since this is a case you care > about making sure you get the right one. > > Let me know if I still missed your main question. Thanks. I guess I don't understand why I have two different places to specify a pre-req plug-in version. But: feature.xml can specify only a specific version and MANIFEST.MF can specify a range. What is the point? (I gave up on page 3 of Google results looking for a decent explanation of feature.xml.... :-) Also, I have a bit of a chicken-and-egg thing, since I need o.a.c.collections 3.2.2 in my target platform before I can change the pre-req, and I have no idea where it comes from. :-)
(In reply to Brian Vosburgh from comment #11) > > Also, I have a bit of a chicken-and-egg thing, since I need > o.a.c.collections 3.2.2 in my target platform before I can change the > pre-req, and I have no idea where it comes from. :-) download.eclipse.org/tools/orbit/downloads/drops/M20151118145958/repository/plugins/org.apache.commons.collections_3.2.2.v201511171945.jar is the copy from the latest Orbit build. (Note- this is not a release build, and will be deleted at some point.)
Changes pushed
The build failed again with following error: [ERROR] Failed to execute goal org.eclipse.tycho:tycho-compiler-plugin:0.21.0:compile (default-compile) on project org.eclipse.jpt.common.utility.tests: Compilation failure: Compilation failure: [ERROR] /jobs/genie.webtools/WTP-R3_8_Integration/workspace/webtools.dali/common/tests/org.eclipse.jpt.common.utility.tests/src/org/eclipse/jpt/common/utility/tests/internal/ArrayToolsTests.java:[4419] [ERROR] a = ArrayTools.sort(a, ComparatorTools.reverseComparator()); [ERROR] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [ERROR] Type mismatch: cannot convert from Object[] to String[]
Build failed again with another error. See comment above.
Not exactly related to this bug.... :-) This looks like a possible compiler bug, depending on the Java spec (?). From what I can tell it looks like when the compiler compiles the following lines of code: String[] a = new String[] { "a", "b", "c", "z" }; a = ArrayTools.sort(a, ComparatorTools.reverseComparator()); The compiler resolves ArrayTools.sort() to ArrayTools.sort(Object...) when it should be resolving to ArrayTools.sort(Object[], Comparator) But I can see this might be a gray area.... Anyway, I tightened up the ArrayTools method signatures, and this should fix the compiler error.
Given your comments in comment 16, you are saying this is due to a change in the compiler level you all use? And not due to a change in "commons.collections"? If a compiler change (or, bug?) I'm sure JDT team would be interested, so have CC'd him on bug.
I forgot to say: I do not see this compile error in my Mars.1 workspace (i.e. using the Eclipse compiler). I do not know which compiler the build uses.... My [relatively Java spec-ignorant] interpretation is that the Eclipse compiler is resolving the method signature correctly and the build compiler is not. And I do not think this has anything to do with the compiler level we are using. Unless the compiler level changes how method signatures are resolved (which might be possible...).
Builds are using Java 8 compiler for 3.8.0 builds which is for Neon and the minimum Java level for Neon is Java 8. That could be causing the issue ?
(In reply to Brian Vosburgh from comment #11) > Thanks. I guess I don't understand why I have two different places to > specify a pre-req plug-in version. But: feature.xml can specify only a > specific version and MANIFEST.MF can specify a range. What is the point? (I > gave up on page 3 of Google results looking for a decent explanation of > feature.xml.... :-) You CAN specify ranges in feature.xml [1], but frankly, you don't have to put feature-level requirements in at all, especially if you build with Tycho. MANIFEST.MF requirements are better for setting up dependencies. [1] http://divby0.blogspot.ca/2011/07/manifestmf-and-featurexml-versioning.html If you need to ensure a requirement appears on an update site (which is one reason why feature includes exist), a better approach is to simply add the <bundle/>s to the category.xml rather than hoping the feature.xml will drag in all the missing IUs [2]. [2] https://github.com/jbosstools/jbosstools-build-sites/blob/master/aggregate/site/category.xml#L42-L43 > Also, I have a bit of a chicken-and-egg thing, since I need > o.a.c.collections 3.2.2 in my target platform before I can change the > pre-req, and I have no idea where it comes from. :-) It comes from Eclipse Orbit I20151117200049 [3]. Here's an update site [4]. [3] http://download.eclipse.org/tools/orbit/downloads/drops/I20151117200049/ [4] http://download.eclipse.org/tools/orbit/downloads/drops/I20151117200049/repository/ Hope that explains / helps!
