| These are not security fixes you can apply blindly. We strongly recommend you read this post, as well as the security advisory to understand what the vulnerabilities are, whether and how they affect you, and what to expect when upgrading plugins. |
Multiple Jenkins plugins received updates today that fix several security vulnerabilities or other security-related issues:
We also included some plugins that received security fixes in the past that haven’t been mentioned in a security advisory before:
Additionally, we included other plugins in the advisory that are not getting updated today, but whose vulnerabilities are similar to those of plugins getting fixed. In total, over 30 plugins are part of the advisory.
While there are fixes for other vulnerabilities as well, the majority of the advisory (and the rest of this blog post) is about arbitrary code execution vulnerabilities in Jenkins plugins.
Background
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.
About the advisory
Broadly speaking, there are three levels of severity for scripting related vulnerabilities in Jenkins:
The lowest severity ones are those that confuse Overall/Administer and Overall/Run Scripts permissions. These are irrelevant for most Jenkins instances. More on that later.
The next level up are vulnerabilities that effectively grant the ability to run arbitrary scripts to users who are able to configure jobs. While these users aren’t administrators, they have a nontrivial level of permissions, so are somewhat trusted. This is often a difficult configuration to adequately secure, but it’s a supported configuration, and any plugin that undermines the security of this configuration will be treated as having a vulnerability.
The most severe ones are those that require little or no access to Jenkins to successfully exploit. This typically does require the Overall/Read permission to access certain endpoints, but Pipeline as Code may allow people with SCM commit access to exploit scripting related weaknesses as well.
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.
How to proceed
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.
If the vulnerability confuses Overall/Administer and Overall/Run Scripts, but all administrators of your Jenkins instance are able to run scripts anyway, this vulnerability is not a problem for you. This is the case in the vast majority of Jenkins instances. Only custom setups, typically to allow for hosted Jenkins services, don’t grant Overall/Run Scripts permission to administrators.
If the vulnerability allows users with the permission to e.g. configure jobs to execute arbitrary code, it is only a problem if there are users that have the lower permission (e.g. Item/Configure) but not the higher (Overall/Run Scripts). Simple authorization strategies like Logged in users can do anything are therefore not affected by this issue.
Even vulnerabilities that require no notable permissions in Jenkins may have prerequisites to be exploitable. For example, Overall/Read access may be required, but only granted to users who are also administrators, or in Pipeline as Code setups, everyone with SCM commit access may also be a Jenkins administrator.
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.
Distributing vulnerable plugins
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.