groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From JamieEchlin <>
Subject security issue with @ASTTest
Date Thu, 08 Oct 2015 07:47:34 GMT

Many people (myself anyway) are probably using variations of type checking
scripts to increase security -

But these are trivially bypassed with the ASTTest annotation, eg:

import groovy.transform.ASTTest
import org.codehaus.groovy.control.CompilePhase

@ASTTest(phase = CompilePhase.SEMANTIC_ANALYSIS, value = {
    println "pwned"
class Temp extends Script {
    Object run() {

All the "hacker" needs to do is choose a phase earlier than the one the type
checking script runs in, and they can execute any code in the value closure.

This can't be prevented either by the sandboxing type-checking Cedric
proposed, or org.codehaus.groovy.control.customizers.SecureASTCustomizer
(which runs in CANONICALISATION phase).

As Cedric points out this is true of any global transform on the classpath,
however ASTTest is the only one (afaik, is this true?) that allows
user-supplied code to be run during the compilation process.

My response to that point would be that if the implementor has added
additional transforms that's their responsibility. But ASTTest is actually
in the standard distribution, which means everyone embedding groovy needs to
take special care to deal with it.

My suggestion is that it be moved to a different jar not part of groovy-all.
AFAIK (again), the only way to protect against it is to ship your own
distribution of groovy that removes it.

Even if you have an extension to check it that runs at
Phases.INITIALIZATION, the user script AST could run at the same phase, and
I don't know which would be called first. 

cheers, jamie

PS Sorry if you get this twice, I think I was subscribed to the old list.

View this message in context:
Sent from the Groovy Dev mailing list archive at

View raw message