Morning,
Many people (myself anyway) are probably using variations of type checking
scripts to increase security -
ref:http://melix.github.io/blog/2015/03/sandboxing.html
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 {
@Override
Object run() {
false
}
}
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:
http://groovy.329449.n5.nabble.com/security-issue-with-ASTTest-tp5728150.html
Sent from the Groovy Dev mailing list archive at Nabble.com.
