This isn't a security problem

[pbuckley4192]

This isn't a security problem

[pbuckley4192]

Sigh...its still not a security problem... You used jenkins the way it was meant to be used... you logged in and performed an action withtin the limits the system allows, no trickery to achieve "RCE"... its not an exploit. Its a script on how to add a command to a job.

[farisv]

@pbuckley4192 can you provide a proof of concept where logged in user with the ability to 'performed an action within the limits the system allows' can execute shell inside master node?

Indeed, a user with Administrator right or Overall/RunScripts permission can use /script to execute shell via Groovy script, directly on the master node. But, suppose that a user only has access to a certain job inside distributed Jenkins. That job will execute some build scripts inside the slave node.

Usually, we can add groovy script to execute shell command inside the slave node. Example:

node {
  sh "cat /etc/passwd"
}

That is the intended way of Jenkins, the one that was meant to be used because it's a feature. But, that user can't perform shell execution inside the master node. That's why the vulnerability described in https://cxsecurity.com/issue/WLB-2019020120 is indeed a mislead and actually a feature (not security vulnerability). But, the one in this repository is actually a vulnerability.

Example, we can use this script to execute shell with Groovy.

def sout = new StringBuilder(), serr = new StringBuilder()
def proc = 'cat /etc/passwd'.execute()
proc.consumeProcessOutput(sout, serr)
proc.waitForOrKill(1000)
println "out> $sout err> $serr"

But it will be rejected when you try to build because of sandbox/scriptsecurity.

When you use this Groovy script:

import org.buildobjects.process.ProcBuilder
@Grab('org.buildobjects:jproc:2.2.3')
class Dummy{ }
print new ProcBuilder("/bin/bash").withArgs("-c","cat /etc/passwd").run().getOutputString()

It will be executed and that's not the intended usability. It's because the unpatched Jenkins allows @Grab which is an AST annotation to load external module (http://groovy-lang.org/metaprogramming.html). The patched Jenkins now disallow @Grab.

The security implication of this is, the user with limited access (only can execute shell inside slave node ) can use this vulnerability to execute shell inside the master node. Imagine a big organization with hundreds of engineers. Only one has access to execute shell in master node and the rest only has access to execute shell in slave nodes for certain projects. This is indeed a security vulnerability.

The other scenario of this vulnerability (besides the one that is in this repository), a user with very limited permission (only Overall/Read, cannot configure or run job) can use this URL to execute sandboxed Groovy script.

https://URL/descriptorByName/org.jenkinsci.plugins.workflow.cps.CpsFlowDefinition/checkScriptCompile?value=[script]

With the same vulnerability (but the different way of exploit), we can bypass the sandbox and user with Overall/Read permission can execute shell inside the master node.

Do you want the RCE without authentication at all? Combine with http://blog.orange.tw/2019/01/hacking-jenkins-part-1-play-with-dynamic-routing.html.

CMIIW

[adamyordan]

Hi @pbuckley4192, As specified in README.md, you need Job/Configure permission for this exploit to work.

This exploit allows user (more specifically, regular non-administrative user) to bypass the sandbox protection and execute arbitrary code on the Jenkins server, whereas that is not the intended usage of Jenkins.

[adamyordan]

You may also want to check out an article regarding the full exploit chain authored by the CVE reporter. I think they will publish it next week.

The exploit chain may allow you to do RCE without the need of Job/Configure permission.

[pbuckley4192]

@farisv Great writeup!! @adamyordan please put @farisv 's comment in the readme as an explaination!
Confirmed it with my production Jenkins (Jenkins with ~100 users), a Read only user was able to obtain a shell using that @grab