Jenkins Security Advisory 2022-05-17

Pipeline: Groovy Plugin allows pipelines to load Groovy source files. This is intended to be used to allow Global Shared Libraries to execute without sandbox protection.

In Pipeline: Groovy Plugin 2689.v434009a_31b_f1 and earlier, any Groovy source files bundled with Jenkins core and plugins could be loaded this way and their methods executed. If a suitable Groovy source file is available on the classpath of Jenkins, sandbox protections can be bypassed.

Pipeline: Groovy Plugin 2692.v76b_089ccd026 restricts which Groovy source files can be loaded in Pipelines.

Groovy source files in public plugins intended to be executed in sandboxed pipelines have been identified and added to an allowlist. The new extension point org.jenkinsci.plugins.workflow.cps.GroovySourceFileAllowlist allows plugins to add specific Groovy source files to that allowlist if necessary, but creation of plugin-specific Pipeline DSLs is strongly discouraged.

Script Security Plugin 1158.v7c1b_73a_69a_08 and earlier does not require POST requests for a form validation endpoint, resulting in a cross-site request forgery (CSRF) vulnerability.

This vulnerability allows attackers to have Jenkins send an HTTP request to an attacker-specified webserver.

This form validation method no longer sends HTTP requests in Script Security Plugin 1172.v35f6a_0b_8207e.

SCMs support a number of different URL schemes, including local file system paths (e.g. using file: URLs).

Historically in Jenkins, only agents checked out from SCM, and if multiple projects share the same agent, there is no expected isolation between builds besides using different workspaces unless overridden. Some Pipeline-related features check out SCMs from the Jenkins controller as well.

This allows attackers able to configure pipelines to check out some SCM repositories stored on the Jenkins controller’s file system using local paths as SCM URLs, obtaining limited information about other projects' SCM contents. The following Jenkins plugins are known to be affected:

Affected plugins have been updated to reject local file paths being checked out on the controller:

WMI Windows Agents Plugin 1.8 and earlier includes the Windows Remote Command library. It provides a general-purpose remote command execution capability that Jenkins uses to check if Java is available, and if not, to install it.

This library has a buffer overflow vulnerability that may allow users able to connect to a named pipe to execute commands on the Windows agent machine.

Additionally, while the processes are started as the user who connects to the named pipe, no access control takes place, potentially allowing users to start processes even if they’re not allowed to log in.

WMI Windows Agents Plugin 1.8.1 no longer includes the Windows Remote Command library. A Java runtime is expected to be available on agent machines and WMI Windows Agents Plugin 1.8.1 does not install a JDK automatically otherwise.

When pipelines are created using the pipeline creation wizard in Blue Ocean, the credentials used are stored in the per-user credentials store of the user creating the pipeline. To allow pipelines to use this credential to scan repositories and checkout from SCM, the Blue Ocean Credentials Provider allows pipelines to access a specific credential from the per-user credentials store in Pipeline SCM API for Blue Ocean Plugin 1.25.3 and earlier.

As a result, attackers with Job/Configure permission can rewrite job configurations in a way that lets them access and capture any attacker-specified credential from any user’s private credentials store.

Pipeline SCM API for Blue Ocean Plugin 1.25.4 deprecates the Blue Ocean Credentials Provider and disables it by default. As a result, all jobs initially set up using the Blue Ocean pipeline creation wizard and configured to use the credential specified at that time will no longer be able to access the credential, resulting in failures to scan repositories, checkout from SCM, etc. unless the repository is public and can be accessed without credentials.

Administrators should reconfigure affected pipelines to use a credential from the Jenkins credential store or a folder credential store. See this help page on cloudbees.com to learn more.

To re-enable the Blue Ocean Credentials Provider, set the Java system property io.jenkins.blueocean.rest.impl.pipeline.credential.BlueOceanCredentialsProvider.enabled to true. Doing so is discouraged, as that will restore the unsafe behavior.

Administrators not immediately able to update Blue Ocean are advised to disable the Blue Ocean Credentials Provider through the UI at Manage Jenkins » Configure Credential Providers and to reconfigure affected pipelines to use a credential from the Jenkins credential store or a folder credential store.

Blue Ocean Plugin 1.25.3 and earlier does not perform permission checks in several HTTP endpoints.

This allows attackers with Overall/Read permission to send requests to an attacker-specified URL.

Additionally, these endpoints do not require POST requests, resulting in a cross-site request forgery (CSRF) vulnerability.

Blue Ocean Plugin 1.25.4 requires POST requests and the appropriate permissions for the affected HTTP endpoints.

GitLab Plugin 1.5.31 and earlier does not perform a permission check in an HTTP endpoint.

This allows attackers with Overall/Read permission to enumerate credentials IDs of credentials stored in Jenkins. Those can be used as part of an attack to capture the credentials using another vulnerability.

An enumeration of credentials IDs in GitLab Plugin 1.5.32 requires the appropriate permissions.

Rundeck Plugin 3.6.10 and earlier does not restrict URL schemes in Rundeck webhook submissions.

This results in a stored cross-site scripting (XSS) vulnerability exploitable by attackers able to submit crafted Rundeck webhook payloads.

Rundeck Plugin 3.6.11 sanitizes URLs submitted in Rundeck webhook payloads.

SSH Plugin 2.6.1 and earlier does not perform a permission check in an HTTP endpoint.

This allows attackers with Overall/Read permission to enumerate credentials IDs of credentials stored in Jenkins. Those can be used as part of an attack to capture the credentials using another vulnerability.

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

SSH Plugin 2.6.1 and earlier does not perform a permission check in an HTTP endpoint.

This allows attackers with Overall/Read permission to connect to an attacker-specified SSH server using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins.

Additionally, this endpoint does not require POST requests, resulting in a cross-site request forgery (CSRF) vulnerability.

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

Multiple plugins do not escape the name and description of the parameter types they provide:

This results in stored cross-site scripting (XSS) vulnerabilities exploitable by attackers with Item/Configure permission.

Exploitation of these vulnerabilities requires that parameters are listed on another page, like the "Build With Parameters" and "Parameters" pages provided by Jenkins (core), and that those pages are not hardened to prevent exploitation. Jenkins (core) has prevented exploitation of vulnerabilities of this kind on the "Build With Parameters" and "Parameters" pages since 2.44 and LTS 2.32.2 as part of the SECURITY-353 / CVE-2017-2601 fix. Additionally, several plugins have previously been updated to list parameters in a way that prevents exploitation by default, see SECURITY-2617 in the 2022-04-12 security advisory for a list.

The following plugins have been updated to escape the name and description of the parameter types they provide in the versions specified:

As of publication of this advisory, there is no fix available for the following plugins:

Autocomplete Parameter Plugin 1.1 and earlier does not require POST requests for a form validation endpoint executing a provided Groovy script, resulting in a cross-site request forgery (CSRF) vulnerability.

This vulnerability allows attackers to execute arbitrary code without sandbox protection if the victim is an administrator.

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

Autocomplete Parameter Plugin 1.1 and earlier references Dropdown Autocomplete parameter and Auto Complete String parameter names in an unsafe manner from Javascript embedded in view definitions.

This results in a stored cross-site scripting (XSS) vulnerability exploitable by attackers with Item/Configure permission.

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

Storable Configs Plugin 1.0 and earlier does not configure its XML parser to prevent XML external entity (XXE) attacks.

This allows attackers with Item/Configure permission to have Jenkins parse a crafted file that uses external entities for extraction of secrets from the Jenkins controller or server-side request forgery.

Additionally, the HTTP endpoint calling the XML parser does not require POST requests, resulting in a cross-site request forgery (CSRF) vulnerability.

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