| Summary: | <dev-java/groovy-2.4.5: remote execution of untrusted code in class MethodClosure (CVE-2015-3253) | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Agostino Sarubbo <ago> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | java |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://bugzilla.redhat.com/show_bug.cgi?id=1243934 | ||
| See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=575876 https://bugs.gentoo.org/show_bug.cgi?id=605690 |
||
| Whiteboard: | B2 [glsa cve] | ||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 421503 | ||
I've got groovy-2.4.5 baking in my git repo. I'm polishing it up but I will soon push it after Chewi's reviewed it. commit 52d0cdf (HEAD, master) Author: Patrice Clement <monsieurp@gentoo.org> Date: Sun Nov 1 21:32:31 2015 +0000 dev-java/groovy: Version bump. Fixes security bug 555470. Package-Manager: portage-2.2.20.1 Signed-off-by: Patrice Clement <monsieurp@gentoo.org> create mode 100644 dev-java/groovy/files/groovy-2.4.5-utils.gradle.patch create mode 100644 dev-java/groovy/groovy-2.4.5.ebuild Arch teams Please stabilise: =dev-java/groovy-2.4.5 Target arches: amd64 ppc ppc64 x86 Thank you. As discussed on irc, arches will CC'ed in the future because there is a depend problem. dev-java/groovy/groovy-2.4.5.ebuild: DEPEND: amd64(default/linux/amd64/13.0) ['>=dev-java/antlr-2.7.7-r7:0'] (In reply to Agostino Sarubbo from comment #3) > As discussed on irc, arches will CC'ed in the future because there is a > depend problem. > > dev-java/groovy/groovy-2.4.5.ebuild: DEPEND: amd64(default/linux/amd64/13.0) > > ['>=dev-java/antlr-2.7.7-r7:0'] This could be replaced with dev-java/antlr:0[java(+),script(+)]. I was trying to avoid overcomplicating the antlr migration and I will stabilize most of the other revdeps at the same time to avoid conflicts but security takes priority here. Arch teams, please proceed. James sorted out antlr and friends. ping! Could someone get the stabilisation process started? amd64 stable commit 2aec634618a88d0b7eb1e74f2928b0b914253eea (HEAD -> master) Author: Patrice Clement <monsieurp@gentoo.org> AuthorDate: Mon Mar 14 21:56:55 2016 +0000 Commit: Patrice Clement <monsieurp@gentoo.org> CommitDate: Mon Mar 14 21:56:55 2016 +0000 dev-java/groovy: Stable for ppc64+x86. Fixes security bug 555470. As per IRC discussion with Agostino. Package-Manager: portage-2.2.26 dev-java/groovy/groovy-2.4.5.ebuild | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) commit 877eab10c21a927385a599b29b73dd0fe7a9d7ba (HEAD -> master) Author: Patrice Clement <monsieurp@gentoo.org> AuthorDate: Mon Mar 14 21:58:42 2016 +0000 Commit: Patrice Clement <monsieurp@gentoo.org> CommitDate: Mon Mar 14 21:58:42 2016 +0000 dev-java/groovy: Clean up vulnerable versions. Fixes security bug 555470. Package-Manager: portage-2.2.26 dev-java/groovy/Manifest | 2 -- dev-java/groovy/files/groovy-1.8-build-pref-locking-fix.patch | 12 ---------- dev-java/groovy/groovy-1.7.5.ebuild | 118 --------------------------------------------------------------------------------------------------- dev-java/groovy/groovy-1.8.5-r1.ebuild | 124 -------------------------------------------------------------------------------------------------------- 4 files changed, 256 deletions(-) delete mode 100644 dev-java/groovy/files/groovy-1.8-build-pref-locking-fix.patch delete mode 100644 dev-java/groovy/groovy-1.7.5.ebuild delete mode 100644 dev-java/groovy/groovy-1.8.5-r1.ebuild Security, please vote. New GLSA requested. This issue was resolved and addressed in GLSA 201610-01 at https://security.gentoo.org/glsa/201610-01 by GLSA coordinator Sergey Popov (pinkbyte). |
From ${URL} : It was reported that when an application has Groovy on the classpath and that it uses standard Java serialization mechanim to communicate between servers, or to store local data, it is possible for an attacker to bake a special serialized object that will execute code directly when deserialized. All applications which rely on serialization and do not isolate the code which deserializes objects are subject to this vulnerability. Mitigation: Apply the following patch on the MethodClosure class (src/main/org/codehaus/groovy/runtime/MethodClosure.java): public class MethodClosure extends Closure { + private Object readResolve() { + throw new UnsupportedOperationException(); + } Alternatively, you should make sure to use a custom security policy file (using the standard Java security manager) or make sure that you do not rely on serialization to communicate remotely. External References: http://seclists.org/oss-sec/2015/q3/121 @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.