Important Scripting-related Security Advisory

Jenkins administrators have long been able to use the Groovy script console and related functionality to execute arbitrary code in Jenkins for diagnostic or otherwise administrative purposes. Rather than having to rely on plugins implementing the desired functionality, experienced Jenkins admins were able to run a number of scripts as needed to implement various administrative features.

This bled over into plugins: It’s just easy for a plugin developer to build on top of Groovy and let the users figure out exactly what they want to do. Unfortunately, for a long time, there was no technology in Jenkins to limit what could be done in Groovy scripts, so anywhere Groovy would be executed, arbitrary code could be executed.

We were treating this as a security issue for the first time in the fix for SECURITY-125, about two years ago, something that first required splitting off the Matrix Project type from core into a plugin, and making use of Script Security Plugin.

Unfortunately, other plugins weren’t integrating with Script Security plugin. And even diligent administrators who understand the problem of arbitrary code execution via Groovy scripts may not be able to tell whether a given plugin is affected: In some cases, you’d need to dive into the source code to see whether, and how, it uses Groovy in a way that can be exploited by regular users to perform actions they otherwise wouldn’t be allowed to do.

Broadly speaking, there are three levels of severity for scripting related vulnerabilities in Jenkins:

Arbitrary code execution is a serious enough issue that publishing a security advisory for just a few plugins would actually be detrimental to overall security: Malicious users would be able to review the fixes we do publish, and try to find other plugins affected by a similar vulnerability.

The advisory issued today lists all plugins we could find that implement any arbitrary code execution vulnerability (i.e. all three levels described above). As this affects over 30 plugins, many of them not actively maintained, the problem exceeds the capacity of the Jenkins security team to address them all.

For that reason, the Jenkins security team decided that we would fix as many of the plugins as we can handle, and leaving the others to their maintainers.

We strongly advise administrators to review the list of affected plugins in the advisory, and look for any plugins that are installed on their instances. It is very likely there’s at least one plugin installed that is affected by this. If you’re on Jenkins 2.40 or newer, or Jenkins LTS 2.32.2 or newer, a warning will appear that informs you about vulnerable plugins you currently have installed.

Once you’ve determined which plugins you use are included in the advisory, you need to determine whether it is something that affects your particular setup.

The above should guide your decision how urgently you should upgrade affected plugins with a fix, or disable affected plugins without a fix. Remember that you may decide in the future to reconfigure Jenkins in a way that makes previously irrelevant permission distinctions a huge problem, so it is not a good idea to continue using vulnerable plugin versions indefinitely.

After deciding to upgrade a plugin, review the advisory and the plugin documentation for information about the migration. The scripts provided in this GitHub repository may help you in determining whether you’re using affected features. If you’re not using any of the affected features, it’s likely that there won’t be any problems and you can just upgrade. If you are using affected features, you should carefully read the documentation on how the upgrade works: Affected plugin features may effectively be disabled until an administrator approves the scripts in use, potentially resulting in build failures.

Finally, there’s the issue of distribution: The Jenkins project historically has performed little to no oversight over the plugins that are being published. This is a direct consequence of the governance document, which gives plugin maintainers a lot of control over their plugins.

That said, in exceptional circumstances, the Jenkins project can, and should, protect its users: If a plugin maintainer were to upload a clearly malicious plugin, we wouldn’t stand by the side and continue distributing it. In the case of plugins with known (unintended) vulnerabilities, this obviously becomes more difficult. This has been discussed in the abstract a while back on the jenkinsci-dev mailing list, and the majority of participants in that discussion agreed that we should suspend distribution of vulnerable plugins if the security team doesn’t have the capacity to address the problem, and the vulnerability would remain unfixed otherwise.

We decided to temporarily suspend distribution of plugins via the Jenkins project update sites if they allow users with lower privileges (no Overall/Administer) to execute arbitrary code. Users who really need to download these plugins can do so via our Artifactory Maven repository. Once an affected plugin receives a fix, we’d of course resume distribution via the update sites.

Plugins that mistake Overall/Administer and Overall/Run Scripts continue being distributed, albeit with a warning shown to Jenkins administrators, as the setup required for this to make a difference is pretty rare.

Unfortunately, we were unable to adequately inform all plugin maintainers before publication of the advisory, so there are several plugins with fewer than 500 installations that are actively maintained but whose maintainers we didn’t contact prior to this advisory. For that, I am really sorry, and can only ask for understanding from the maintainers of affected plugins. The number of affected plugins and the coordination and review required simply exceeded our capabilities.

Subscribe to the jenkinsci-advisories mailing list to receive important notifications related to Jenkins security.