CloudBees Security Advisory 2017-04-10

This advisory announces vulnerabilities and security-related changes in these Jenkins plugins that are part of the CloudBees Jenkins Solution:

  • CloudBees Role-Based Access Control
  • Email Extension (Email-ext)
  • Matrix Authorization Strategy

The Jenkins project also announces vulnerabilities and security-related changes in these Jenkins plugins:

  • Adaptive DSL
  • Application Detector
  • Artifact Deployer
  • Build Flow
  • CAS
  • CAS protocol version 1
  • Claim
  • CVS Tagging
  • Dynamic Parameter
  • Environment Injector (EnvInject) (2 vulnerabilities)
  • Extensible Choice Parameter
  • Extreme Notification
  • Grails
  • Groovy
  • GroovyAxis
  • Job DSL (2 vulnerabilities)
  • Lockable Resources
  • Ontrack
  • Post-Build Script
  • Process Cleaner
  • PTC Integrity CM
  • Reactor
  • Role-based Authorization Strategy
  • Script SCM
  • Scriptler (5 vulnerabilities)
  • scripttrigger
  • Shared Objects
  • Splunk
  • Splunk Extension
  • Subversion Tagging
  • tcl
  • Warnings (2 vulnerabilities)
  • youtrack-plugin

Additionally, the following plugins had their vulnerability published and fixed in the past, but haven’t been included in a security advisory:

  • Active Choices
  • Extended Choice Parameter
  • Groovy Postbuild
  • Groovy Label Assignment

Due to the number of affected plugins, the list of issues below is split into three parts:

  1. Arbitrary code execution vulnerabilities lists issues that allow users with relatively low privileges (Overall/Read or Job/Configure to run arbitrary code in Jenkins. This means that they can configure all parts of Jenkins (including granting their own user Overall/Administer permission, shutting down Jenkins, running any shell command on any connected agent, etc. In Jenkins, this is a privilege escalation vulnerability: While administrators are typically able to run arbitrary scripts, other users are not.
  2. Script execution protected by wrong permission lists issues that allow users with Overall/Administer permission to run arbitrary code. In typical Jenkins deployments, Overall/Administer implies Overall/Run Scripts, but in certain situations, such as hosted Jenkins setups, this may not always be the case.
  3. Others collects a number of other issues that don’t fit into either of the previous two categories.
     

Arbitrary code execution vulnerabilities

All of these allow users with relatively low privileges (like Overall/Read or Job/Configure) to run arbitrary code in Jenkins.

These issues are typically resolved by either requiring approval by an administrator with Overall/Run Scripts permission before executing the script, or by running the script in a sandbox that only allows execution of whitelisted methods.

If you are upgrading any of these plugins to a version containing a fix, and use the affected scripting features, an administrator will typically have to approve entire scripts or whitelist specific methods for these features to resume working (see Script Security Plugin documentation). Meanwhile, certain features may not work as before the upgrade.

Active Choices (uno-choice) Plugin

JENKINS-28732

This plugin allowed users with Job/Configure permissions to run arbitrary Groovy code inside the Jenkins JVM.

This vulnerability has been previously disclosed, and fixed in Active Choices Plugin 1.5.1, independently released by its maintainer in 2016.

Adaptive DSL Plugin

SECURITY-457

This plugin allows users with Job/Configure permissions to run arbitrary Groovy code inside the Jenkins JVM.

As of publication of this advisory, there is no fix.

Application Detector Plugin

SECURITY-494

This plugin allows Jenkins administrators to run arbitrary Groovy code inside the Jenkins JVM to determine whether an application is installed.

This plugin also allowed users with Overall/Read access to Jenkins to invoke a form validation method that allowed them to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.

As of publication of this advisory, there is no fix.

Artifact Deployer Plugin

SECURITY-294

This plugin allows users with Job/Configure permissions to run arbitrary Groovy code inside the Jenkins JVM by configuring a Groovy script to be executed when the build is deleted (labeled Execute a groovy script when the job is deleted).

As of publication of this advisory, there is no fix.

Build Flow Plugin

SECURITY-293

Build Flow Plugin implements a DSL for orchestrating a build pipeline. As this DSL is not running in a Sandbox, it allows users with Job/Configure permissions for a Build Flow job to run arbitrary Groovy code inside the Jenkins JVM.

While the Build Flow Plugin does not reconfigure the DSL script when a user without Overall/Run Scripts permission submits the job configuration form, this does not affect other methods of sending an updated job configuration to Jenkins, such as POST config.xml (remote API) or the update-job CLI command.

As of publication of this advisory, there is no fix.

CAS Plugin

SECURITY-488

This plugin allows Jenkins administrators to run arbitrary Groovy code inside the Jenkins JVM to determine group memberships.

This plugin also allowed users with Overall/Read access to Jenkins to invoke a form validation method that allowed them to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.

As of publication of this advisory, there is no fix.

CAS protocol version 1 Plugin

SECURITY-491

This plugin allows Jenkins administrators to run arbitrary Groovy code inside the Jenkins JVM to determine group memberships.

This plugin also allowed users with Overall/Read access to Jenkins to invoke a form validation method that allowed them to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.

As of publication of this advisory, there is no fix.
CVS Tagging Plugin

SECURITY-459

CVS Tagging Plugin allows specifying a Groovy GString expression to define the tag for the build. This allows users with Item/Configure permission to run arbitrary Groovy code inside the Jenkins JVM.

This plugin also allowed users with Overall/Read access to Jenkins to invoke a form validation method that allowed them to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.

As of publication of this advisory, there is no fix.

Dynamic Parameter Plugin

SECURITY-462

Dynamic Parameter Plugin allows users with Job/Configure permission to define scripts to be executed on the Build With Parameters form to determine available parameter values.

This allows users with Item/Configure permission to run arbitrary Groovy code inside the Jenkins JVM.

As of publication of this advisory, there is no fix.

Email Extension (email-ext) Plugin

SECURITY-257

The following features allowed users with Item/Configure permission to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts:

  • Script Trigger - Before Build: As the build starts to determine whether to send an email
  • Script Trigger - After Build: Once the build finished to determine whether to send an email
  • Pre-send Script: Run a script before sending email to e.g. determine whether to actually send it.
  • Post-send Script: Run a script after sending email
  • Groovy and Jelly templates from workspaces

Since users without permission to access Jenkins, but SCM commit permissions, could affect the contents of Groovy and Jelly templates in project workspaces, that part of this vulnerability extends to users without access to Jenkins.

This has been addressed in Email Extension Plugin version 2.57.2 by integrating with Script Security Plugin.

Global/default pre-send and post-send scripts are automatically approved, so any jobs with $DEFAULT_PRESEND_SCRIPT and $DEFAULT_POSTSEND_SCRIPT will continue to run outside the sandbox.

Custom pre-send and post-send scripts first have their variables expanded, and are then checked for whole-script approval. If they are approved, they run as is, and if not, an attempt is made to run them in the script sandbox.

However, when a job configuration form is submitted, the script is sent for administrator approval verbatim, which means variables are not expanded. Therefore any script containing but not equal to expandable variables will be submitted to script approval, but that approval will not allow them to run. They will always be running in the sandbox. This is a known limitation.

Any template provided by a Jenkins administrator (e.g. in the master’s scripts/ directory) will run as is outside the sandbox.

The behavior of templates loaded from the build’s workspace depends on the type of template:

  • Jelly-based templates have to be approved by administrators.
  • Groovy-based templates will be checked for approval, and, unless previously approved, will run in the sandbox.

Script-based triggers are configured to need whole-script approval on upgrading, but users configuring the job can choose to run them in the script sandbox instead.

Classpaths no longer support variables, they need to be paths to files on the Jenkins master.

Any failures to run these scripts will result in build failures.

To find out whether you’re likely to be impacted by these changes, use these scripts.

Environment Injector (envinject) Plugin

SECURITY-256

This plugin allowed users with Job/Configure permissions to run arbitrary Groovy code inside the Jenkins JVM by configuring a Groovy script to be executed before a build starts, effectively elevating privileges to Overall/Run Scripts.

The fix for SECURITY-86 previously implemented in Environment Injector Plugin version 1.88 is ineffective, as it only prevents reconfiguring the script via form submission. Users can still submit a job configuration using POST config.xml or the update-job CLI command.

This has been addressed in Environment Injector Plugin version 2.0 by integrating with Script Security Plugin.

After upgrading the plugin, any previously defined Groovy script will be checked for approval, and submitted for approval if it isn’t, and then attempted to run in the sandbox.

When configuring a job, users can choose to run Environment Injector scripts in the sandbox. If so, the methods called in the script are subject to Script Security Groovy sandbox whitelisting. If not, and the user configuring the job is not an administrator, the script will be submitted for approval.

Likewise, custom classpath entries are now also subject to approval.

To find out whether you’re likely to be impacted by these changes, use these scripts.

Extended Choice Parameter Plugin

SECURITY-187

This plugin allowed users with Job/Configure permissions to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.

This vulnerability has been previously disclosed, and fixed in Extended Choice Parameter Plugin version 0.63, independently released by its maintainer in 2016.

Extensible Choice Parameter Plugin

SECURITY-123

This plugin allowed users with Job/Configure permissions to run arbitrary Groovy code inside the Jenkins JVM by configuring a Groovy script to be executed to determine valid parameter values, effectively elevating privileges to Overall/Run Scripts.

It also allowed users with Overall/Read access to Jenkins to invoke a form validation method that allowed them to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.

This has been addressed in Extensible Choice Parameter Plugin version 1.4.0 by integrating with Script Security Plugin.

Existing scripts will be executed in the Groovy sandbox by default after updating the plugin. They can be reconfigured to run outside the sandbox, requiring approval by Jenkins administrators instead.

The pre-defined variable jenkins has been removed. Scripts requiring it will need to access jenkins.model.Jenkins.getInstance(). This should never be whitelisted for scripts running inside the sandbox.

To find out whether you’re likely to be impacted by these changes, use these scripts.

Grails Plugin

SECURITY-458

This plugin allows users with Job/Configure permissions to run arbitrary Groovy code inside the Jenkins JVM by configuring a Groovy expression for the <tt>grails.work.dir</tt> option in a job configuration.

As of publication of this advisory, there is no fix.

Groovy Plugin

SECURITY-292

One of the Groovy Plugin’s major features is the ability to run “System Groovy”. This allows users with Job/Configure permissions to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.

While the plugin previously did not allow users to interactively configure System Groovy build steps unless they had the Overall/Run Scripts permission, this could be circumvented by using the Remote API or Jenkins CLI.

This has been addressed in Groovy Plugin version 2.0 by integrating with Script Security Plugin.

To find out whether you’re likely to be impacted by these changes, use these scripts.

Groovy Label Assignment Plugin

JENKINS-27535

This plugin allowed users with Job/Configure permissions to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.

This vulnerability has been previously disclosed, and fixed in Groovy Label Assignment Plugin 1.2.0, independently released by its maintainer in 2016.

Groovy Postbuild Plugin

JENKINS-15212

This plugin allowed users with Job/Configure permissions to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.

This vulnerability has been previously disclosed, and fixed in Groovy Postbuild Plugin 2.0, independently released by its maintainer in 2014.

GroovyAxis Plugin

SECURITY-460

This plugin allows users with Job/Configure permissions to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.

It also allowed users with Overall/Read access to Jenkins to invoke a form validation method that allowed them to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.

As of publication of this advisory, there is no fix.

Job DSL Plugin

SECURITY-369

This plugin allows users with Job/Configure permission to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.

Additionally, since the jobDsl Pipeline step was implemented, anyone with commit access to an SCM repository used by Pipeline can run arbitrary Groovy code on a Jenkins instance with this plugin installed.

This has been addressed in Job DSL version 1.60 by integrating with Script Security Plugin. Script security for Job DSL scripts is now enabled by default if Jenkins security is enabled. As a consequence, DSL scripts have either to be approved by an Jenkins administrator or run in an restricted sandbox. Further limitations apply, see the documentation linked below for details. To restore the old behavior, Job DSL script security can be disabled on the “Configure Global Security” page. It is strongly recommended not to do this.

Lockable Resources Plugin

SECURITY-368

Lockable Resources Plugin allows users with Job/Configure permission to define a label expression to determine the resources to use. If this label expression starts with groovy: the rest of it is evaluated as a Groovy script inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.

This has been addressed in Lockable Resources version 2.0 by integrating with Script Security Plugin.

While this plugin integrates with Pipeline, the vulnerability did not affect this project type.

To find out whether you’re likely to be impacted by these changes, use these scripts.

Ontrack Plugin

SECURITY-495

This plugin allows users with Job/Configure permission to run arbitrary Groovy code inside the Jenkins JVM using the Ontrack DSL feature, effectively elevating privileges to Overall/Run Scripts.

As of publication of this advisory, there is no fix.

Post-Build Script Plugin

SECURITY-295

This plugin allows users with Job/Configure permission to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.

As of publication of this advisory, there is no fix.

Process Cleaner Plugin

SECURITY-489

This plugin allows users with Job/Configure permission to run arbitrary Groovy code inside the Jenkins JVM of the node the build is running on, effectively elevating privileges to Overall/Run Scripts.

As of publication of this advisory, there is no fix.

PTC Integrity CM Plugin

SECURITY-176

This plugin allows users with Job/Configure permissions to run arbitrary Groovy code inside the Jenkins JVM by supplying a Groovy script for the checkpoint label option, effectively elevating privileges to Overall/Run Scripts.

This plugin also allowed users with Overall/Read access to Jenkins to invoke a form validation method that allowed them to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.

As of publication of this advisory, there is no fix.

Reactor Plugin

SECURITY-487

This plugin allows users with Job/Configure permission to run arbitrary Groovy code inside the Jenkins JVM by defining a Reactor Script that will be run when a Reactor Event triggers, effectively elevating privileges to Overall/Run Scripts.

As of publication of this advisory, there is no fix.

Script SCM Plugin

SECURITY-461

This plugin allows users with Job/Configure permission to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.

As of publication of this advisory, there is no fix.

scripttrigger Plugin

SECURITY-456

This plugin allows users with Job/Configure permission to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.

As of publication of this advisory, there is no fix.

Splunk Extension Plugin

SECURITY-493

Splunk Extension Plugin allows users able to configure a Pipeline to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts. This includes both users with Job/Configure privilege, as well as users with SCM commit access (Pipeline as Code).

As of publication of this advisory, there is no fix.

Subversion Tagging Plugin

SECURITY-298

Sybversion Tagging Plugin allows specifying a Groovy GString expression to define the tag for the build. This allows users with Job/Configure permission to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.

This plugin also allowed users with Overall/Read access to Jenkins to invoke a form validation method that allowed them to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.

As of publication of this advisory, there is no fix.

tcl Plugin

SECURITY-379

This plugin allows users with Job/Configure permission to run arbitrary TCL code inside the Jenkins JVM, effectively elevating that permission to Overall/Run Scripts.

As of publication of this advisory, there is no fix.

Warnings Plugin

SECURITY-405

Warnings Plugin allowed users with Overall/Read access to Jenkins to invoke a form validation method that allowed them to run arbitrary Groovy code inside the Jenkins JVM, effectively elevating privileges to Overall/Run Scripts.

This has been addressed in Warnings Plugin 4.61 and the affected form validation methods are now limited to users with Overall/Run Scripts permissions.

Youtrack Plugin

SECURITY-464

Youtrack Plugin allowed users with Job/Configure permission to run arbitrary Groovy code inside the Jenkins JVM as part of a Groovy template for a comment to be posted to Youtrack, effectively elevating that permission to Overall/Run Scripts.

As of publication of this advisory, there is no fix.

Script execution protected by wrong permission

These vulnerabilities are related to the arbitrary code execution vulnerabilities above in that they allow users with insufficient permissions to run arbitrary code. The difference is that all of these require users to have Overall/Administer permission. In typical Jenkins deployments, Overall/Administer implies Overall/Run Scripts, so there is no difference between the two. These are only an issue in very specific circumstances, typically hosted Jenkins environments.

To determine whether these issues affect you, log into Jenkins as administrator, navigate to Manage Jenkins and look for a link titled Script Console. If it exists, you also have Overall/Run Scripts permission.

Claim Plugin

SECURITY-296

Claim Plugin 2.6 and newer allows Jenkins administrators to run arbitrary Groovy code inside the Jenkins JVM to be executed whenever a claim is changed.

This mistakes the Overall/Administer permission for the Overall/Run Scripts permission. For most Jenkins instances, there is no difference between the two, but hosted Jenkins services may be configured to only grant the former, but not the latter.

As of publication of this advisory, there is no fix.

Extreme Notification Plugin

SECURITY-492

Extreme Notification Plugin allows administrators to run arbitrary Groovy code inside the Jenkins JVM as part of notifications.

This mistakes the Overall/Administer permission for the Overall/Run Scripts permission. For most Jenkins instances, there is no difference between the two, but hosted Jenkins services may be configured to only grant the former, but not the latter.

As of publication of this advisory, there is no fix.

Scriptler Plugin

SECURITY-367

Scriptler Plugin allows administrators to run arbitrary Groovy code inside the Jenkins JVM.

This mistakes the Overall/Administer permission for the Overall/Run Scripts permission. For most Jenkins instances, there is no difference between the two, but hosted Jenkins services may be configured to only grant the former, but not the latter.

Additionally, the plugin recommends granting non-admin users the Overall/Run Scripts permission to be able to run specific, preconfigured scripts. This mistakes Overall/Run Scripts for a lesser permission than Overall/Administer.

As of publication of this advisory, there is no fix.

Shared Objects Plugin

SECURITY-493

Shared Objects Plugin allows administrators to run arbitrary Groovy code inside the Jenkins JVM.

This mistakes the Overall/Administer permission for the Overall/Run Scripts permission. For most Jenkins instances, there is no difference between the two, but hosted Jenkins services may be configured to only grant the former, but not the latter.

As of publication of this advisory, there is no fix.

Splunk Plugin

SECURITY-479

Splunk Plugin allows administrators to run arbitrary Groovy code inside the Jenkins JVM.

This mistakes the Overall/Administer permission for the Overall/Run Scripts permission. For most Jenkins instances, there is no difference between the two, but hosted Jenkins services may be configured to only grant the former, but not the latter.

As of publication of this advisory, there is no fix.

Warnings Plugin

SECURITY-297

Warnings Plugin allows administrators to run arbitrary Groovy code inside the Jenkins JVM as part of custom warning parsers.

This mistakes the Overall/Administer permission for the Overall/Run Scripts permission. For most Jenkins instances, there is no difference between the two, but hosted Jenkins services may be configured to only grant the former, but not the latter.

This has been addressed in Warnings Plugin version 4.61 by integrating with Script Security Plugin.

Custom warning parsers are now subject to the Script Security sandbox, and methods used there need to be added to the whitelist before they can be used.

To find out whether you’re likely to be impacted by these changes, use these scripts.

Others

These issues fit in neither of the previous two categories.

Persistent cross-site scripting vulnerability in Scriptler Plugin

SECURITY-333

Administrators are able to submit arbitrary HTML as description of Scriptler scripts that are shown verbatim to other administrators, allowing cross-site scripting attacks.

As of publication of this advisory, there is no fix.

Script management vulnerable to Cross-Site Request Forgery attacks in Scriptler Plugin

SECURITY-334

None of the script management functionality in Scriptler requires POST access, and is therefore vulnerable to CSRF exploits even with CSRF protection enabled in the Jenkins global security configuration.

As of publication of this advisory, there is no fix.

Any user can add Scriptler script build steps to job configurations

SECURITY-365

Scriptler plugin lets users with Overall/Run Scripts or Overall/Administer permission add Scriptler script executions to job configurations. Users without these permissions are not supposed to be able to add this build step to jobs.

The protection mechanism used only affects submission of job configuration forms through the UI and can be circumvented e.g. by sending POST config.xml requests.

As of publication of this advisory, there is no fix.

Scriptler Plugin allows any Scriptler script to be executed as build step

SECURITY-366

Scriptler Plugin executes any Scriptler scripts specified for the Scriptler build step in job configurations even though it is documented to only allow specific scripts to be included.

Users can therefore POST config.xml or use a similar approach to submit a job configuration containing a script that is not available from the UI. Additionally, jobs configured through the UI will continue to run specified scripts even after they have been reconfigured to not allow this inclusion.

As of publication of this advisory, there is no fix.

Environment Injector (EnvInject) Plugin allows low privilege users to access parts of arbitrary files on master

SECURITY-348

Environment Injector Plugin allowed users with Job/Configure permission to include properties files containing an environment definition from the master node.

This also allowed loading contents of files in other formats than Java properties files, with (parts of) the content made available as environment variables to subsequent build steps. This could be used to access secret information on the Jenkins master file system.

This has been addressed in Environment Injector Plugin 2.0.

The plugin now has a new global option Enable file loading from the master. It is disabled by default.

If disabled, any job previously configured to load a file from the master will fail. Once the option in the job has been unset, it’s also removed from the UI so it cannot (accidentally) be enabled again.

If enabled, the behavior is as before. This is strongly discouraged.

Permission check bypass in Job DSL Plugin

SECURITY-363

Job DSL plugin allowed users with the ability to edit Job DSL scripts in Jenkins or SCM to bypass permission checks. This included the following:

  • Redefining all existing items (jobs) without appropriate Item/Read and Item/Configure permission.
  • Deleting existing items (jobs) without Item/Delete permission.
  • Reading item (job) configurations without Item/ExtendedRead permission.
  • Reading files from any workspace without Item/Workspace permission.
  • Starting builds without Item/Build permission.
  • Creating new new items (jobs) without Item/Create permission.
  • Redefining views without View/Read or View/Configure permission.
  • Creating views without View/Create permission.
  • Creating or modifying /userContent directory contents without Overall/Administer permission.
  • Creating or updating config files from Config File Provider Plugin without Overall/Administer permission.

The list above may not be exhaustive.

This has been addressed in Job DSL Plugin 1.60.

Actions performing Jenkins model access or modification now perform permission checks. By default, Jenkins executes all builds as the SYSTEM user with all permissions, but plugins such as Authorize Project allow configuring different build authorizations.

After installing Authorize Project plugin, you will find Access Control for Builds in Manage Jenkins » Configure Global Security. Adding Project default Build Authorization or Per-project configurable Build Authorization enables the Authorize Project plugin.

Choosing Per-project configurable Build Authorization allows the authentication that a job will run as to be configured from the job configuration page. A new side bar menu Authorization will appear in job pages where different strategies can be selected.

CloudBees Role-Based Access Control Plugin allowed configuring dangerous permissions

CJP-6379

The CloudBees Role-Based Access Control Plugin allowed configuring the following permissions independently from Overall/Administer:

  • Overall/Run Scripts
  • Overall/Upload Plugins
  • Overall/Configure Update Center

This gave the impression that these permissions are less powerful than Overall/Administer when the opposite is actually the case. Jenkins just grants these permissions to anyone who has Overall/Administer by default for historical reasons, when in fact, these permissions are intended to be removed from administrators (in specific circumstances, and with plugins allowing to do this) rather than granted to non-administrators.

Administrators unaware of the exact meaning of these permissions may inadvertently grant them to users who are not trusted to be administrators.

This has been addressed in CloudBees Role-Based Access Control Plugin 5.15.

Jenkins administrators will be warned with a message in the roles/groups page when any of the permissions listed above are granted to roles but they don’t also have the Overall/Administer permission. These permissions will be denied if granted to users without Overall/Administer.

Matrix Authorization Strategy Plugin allowed configuring dangerous permissions

SECURITY-410

The Matrix Authorization Strategy Plugin allowed configuring the following permissions independently from Overall/Administer:

  • Overall/Run Scripts
  • Overall/Upload Plugins
  • Overall/Configure Update Center

This gave the impression that these permissions are less powerful than Overall/Administer when the opposite is actually the case. Jenkins just grants these permissions to anyone who has Overall/Administer by default for historical reasons, when in fact, these permissions are intended to be removed from administrators (in specific circumstances, and with plugins allowing to do this) rather than granted to non-administrators.

Administrators unaware of the exact meaning of these permissions may inadvertently grant them to users who are not trusted to be administrators.

This has been addressed in Matrix Authorization Strategy Plugin 1.5.

If none of the affected permissions were granted to users who aren’t also granted the Overall/Administer permission before updating, the UI for doing so is hidden, and there are no behavior changes.

If any of the affected permissions were granted to users who aren’t also granted the Overall/Administer permission before updating, the UI for doing so remains unchanged, the the plugin will only grant these permissions to users who also have Overall/Administer. Additionally, an administrative monitor will inform administrators about this possible misconfiguration. If the additional permissions are then removed from the affected non-admin users, the columns for these permissions will no longer be shown.

If you want to retain the old, unsafe behavior, set the system property hudson.security.GlobalMatrixAuthorizationStrategy.dangerousPermissions to true. The plugin retains permissions configured before upgrading, so there should be no changes in behavior afterwards.

Role-based Authorization Strategy Plugin allowed configuring dangerous permissions

SECURITY-410

The Role-based Authorization Strategy Plugin allowed configuring the following permissions independently from Overall/Administer:

  • Overall/Run Scripts
  • Overall/Upload Plugins
  • Overall/Configure Update Center

This gave the impression that these permissions are less powerful than Overall/Administer when the opposite is actually the case. Jenkins just grants these permissions to anyone who has Overall/Administer by default for historical reasons, when in fact, these permissions are intended to be removed from administrators (in specific circumstances, and with plugins allowing to do this) rather than granted to non-administrators.

Administrators unaware of the exact meaning of these permissions may inadvertently grant them to users who are not trusted to be administrators.

This has been addressed in Role-based Authorization Strategy Plugin 2.4.0.

If none of the affected permissions were granted to users who aren’t also granted the Overall/Administer permission before updating, the UI for doing so is hidden, and there are no behavior changes.

If any of the affected permissions were granted to users who aren’t also granted the Overall/Administer permission before updating, the UI for doing so remains unchanged, the the plugin will only grant these permissions to users who also have Overall/Administer. Additionally, an administrative monitor will inform administrators about this possible misconfiguration. If the additional permissions are then removed from the affected non-admin users, the columns for these permissions will no longer be shown.

If you want to retain the old, unsafe behavior, set the system property org.jenkinsci.plugins.rolestrategy.permissions.DangerousPermissionHandlingMode.enableDangerousPermissions to true. The plugin retains permissions configured before upgrading, so there should be no changes in behavior afterwards.

Severity: 
  • CJP-6379: hardening
  • SECURITY-123: high
  • SECURITY-176: high
  • SECURITY-187: high
  • SECURITY-256: high
  • SECURITY-257: high
  • SECURITY-292: high
  • SECURITY-293: high
  • SECURITY-294: high
  • SECURITY-295: high
  • SECURITY-296: high
  • SECURITY-297: high
  • SECURITY-298: high
  • SECURITY-333: medium
  • SECURITY-334: high
  • SECURITY-348: medium
  • SECURITY-363: high
  • SECURITY-365: high combined with SECURITY-367
  • SECURITY-366: medium
  • SECURITY-367: high combined with SECURITY-365
  • SECURITY-368: high
  • SECURITY-369: critical
  • SECURITY-379: high
  • SECURITY-405: high
  • SECURITY-410: hardening
  • SECURITY-456: high
  • SECURITY-457: high
  • SECURITY-458: high
  • SECURITY-459: high
  • SECURITY-460: high
  • SECURITY-461: high
  • SECURITY-462: high
  • SECURITY-464: high
  • SECURITY-479: high
  • SECURITY-487: high
  • SECURITY-488: high
  • SECURITY-489: high
  • SECURITY-491: high
  • SECURITY-492: high
  • SECURITY-493: high
  • SECURITY-494: high
  • SECURITY-495: high
  • SECURITY-496: critical
  • JENKINS-15212: high
  • JENKINS-27535: high
  • JENKINS-28732: high
Fix: 

For plugins affected by scripting vulnerabilities, upgrading them to releases containing fixes will necessarily require administrators to approve the scripts or specific method signatures used. Builds may fail or otherwise misbehave. Upgrades of these plugins should be performed with this issue in mind if you are using the affected features.

Fixes have been released for the following plugins:

  • Active Choices (uno-choice) Plugin should be updated to version 1.5.1 or newer. As this plugin depends on Scriptler, whose distribution has been suspended, you need to download this plugin from the Jenkins project Maven repository and upload it to Jenkins.
  • CloudBees Role-Based Access Control Plugin should be updated to version 5.15.
  • Email Extension (Email-ext) Plugin should be updated to version 2.57.2.
  • Environment Injector (EnvInject) Plugin should be updated to version 2.0.
  • Extended Choice Parameter Plugin should be updated to version 0.63 or newer.
  • Extensible Choice Parameter Plugin should be updated to version 1.4.0.
  • Groovy Label Assignment Plugin should be updated to version 1.2.0 or newer.
  • Groovy Plugin should be updated to version 2.0.
  • Groovy Postbuild Plugin should be updated to version 2.0 or newer.
  • Job DSL Plugin should be updated to version 1.60.
  • Lockable Resources Plugin should be updated to version 2.0.
  • Matrix Authorization Strategy Plugin should be updated to version 1.5.
  • Role-based Authorization Strategy Plugin should be updated to version 2.4.0.
  • Warnings Plugin should be updated to version 4.61, and its dependency Static Analysis Plugins to version 1.85.

Listed versions include fixes to the vulnerabilities described above. All prior versions containing the affected features are considered affected by these vulnerabilities unless otherwise noted.

Plugins not listed above have not been fixed in time for this security advisory. The Jenkins wiki tracks the current state of these plugins.