Jenkins Security Advisory 2019-07-31

This advisory announces vulnerabilities in the following Jenkins deliverables:

Descriptions

Sandbox bypass through type casts in Script Security Plugin

SECURITY-1465 (1) / CVE-2019-10355

Sandbox protection in Script Security Plugin could be circumvented by casting crafted objects to other types. This allowed attackers able to specify sandboxed scripts to invoke constructors that weren’t approved.

Additionally, this could be used to read arbitrary files on the Jenkins controller.

Casting collections to other types as an alternative syntax for constructor invocation is now only allowed when the collection type is defined in java.util, and prohibited otherwise. Casting files and enums to arrays is now intercepted by the sandbox and treated as the invocation of an equivalent method.

Sandbox bypass through method pointer expressions in Script Security Plugin

SECURITY-1465 (2) / CVE-2019-10356

Sandbox protection in Script Security Plugin could be circumvented through crafted subexpressions used as arguments to method pointer expressions. This allowed attackers able to specify sandboxed scripts to execute arbitrary code in the context of the Jenkins controller JVM.

Method pointer subexpressions are now subject to sandbox protection.

Missing permission check in Pipeline: Shared Groovy Libraries Plugin

SECURITY-1422 / CVE-2019-10357

Pipeline: Shared Groovy Libraries Plugin provides form validation to determine whether the revision (e.g. commit, tag, or branch name) specified for a global library exists in the repository. This form validation method lacked a permission check, allowing attackers with Overall/Read access to determine whether an attacker-specified revision exists in an SCM repository configured for use in an existing shared library.

Pipeline: Shared Groovy Libraries Plugin now performs the appropriate permission check.

Maven Integration Plugin did not mask sensitive values in module build logs

SECURITY-713 / CVE-2019-10358

Maven Integration Plugin did not apply build log decorators from the Build Environment configuration to module builds. This could prevent sensitive content in module build logs from being masked.

Maven Integration Plugin now applies build log decorators from the Build Environment configuration to module builds.

CSRF vulnerability in Maven Release Plug-in Plugin

SECURITY-1098 / CVE-2019-10359

Maven Release Plug-in Plugin did not require that requests sent to the endpoint used to initiate the release process use POST. This resulted in a cross-site request forgery vulnerability that allows attackers to perform releases.

Maven Release Plug-in Plugin now requires that these requests be sent via POST.

Stored XSS vulnerability in Maven Release Plug-in Plugin

SECURITY-1184 / CVE-2019-10360

Maven Release Plug-in Plugin did not properly escape variables in multiple views, resulting in a stored cross-site scripting vulnerability.

Variables on affected views are now escaped.

Maven Release Plug-in Plugin stored credentials in plain text

SECURITY-1435 / CVE-2019-10361

Maven Release Plug-in Plugin stored credentials unencrypted in its global configuration file org.jvnet.hudson.plugins.m2release.M2ReleaseBuildWrapper.xml on the Jenkins controller. These credentials could be viewed by users with access to the Jenkins controller file system.

Maven Release Plug-in Plugin now stores credentials encrypted.

Configuration as Code Plugin failed to mask secrets in system log messages

SECURITY-1279 / CVE-2019-10343

Configuration as Code Plugin logs the changes it applies to the Jenkins system log. Secrets such as passwords should be masked (i.e. replaced with asterisks) in that log to prevent accidental disclosure.

Between Configuration as Code Plugin 0.8-alpha and 1.0, log messages contained values if the values were specified using properties in the YAML file (SECURITY-929).

Since Configuration as Code Plugin 1.1, log messages in Configuration as Code Plugin instead mask values of type Secret, which is used in Jenkins to store the values encrypted on disk. This did not work in many instances, as plugins could use the Secret type to store credentials encrypted on disk while not having the Secret type appear in their Java API.

Configuration as Code Plugin now inspects the type and looks for a field, getter, or constructor argument corresponding to the property, making the secret detection much more robust for the purpose of log message masking.

As a workaround, administrators can configure the logging level of the logger io.jenkins.plugins.casc.Attribute to a level that does not include INFO messages. See the logging documentation for details.

Configuration as Code Plugin allowed users without Overall/Administer permission to access documentation

SECURITY-1290 / CVE-2019-10344

Configuration as Code Plugin provides a generated schema and reference documentation for the configuration options supported on the current Jenkins instance. These URLs did not perform additional permission checks, resulting in their content being available to users with Overall/Read access. This included detailed information about installed plugins that may not be available otherwise.

Access to these URLs is now restricted to users with Overall/Administer permission.

Configuration as Code Plugin did not mask proxy credentials

SECURITY-1303 / CVE-2019-10345

Configuration as Code Plugin provides a custom configurator for the Jenkins proxy configuration.

This feature did not mask the password for logging or encrypt it in the export.

Configuration as Code Plugin 1.20 and newer mask the Jenkins proxy password when logged and only store it encrypted in the export.

Configuration as Code Plugin evaluated variable references when importing a previously exported configuration

SECURITY-1446 / CVE-2019-10362

Configuration as Code Plugin allows exporting the live Jenkins configuration, as well as importing and applying a configuration provided in the same format. One of the features of the import is that it allows specifying variable references (e.g. ${VARIABLE_NAME}) in the configuration YAML file. These will be replaced by the value of the corresponding environment variable (or other source of secrets) during import (interpolation). If such a value should not be interpolated, the escape character ^ can be used before (e.g. ^${VARIABLE_NAME}).

Exporting did not add ^ escape characters to exported strings, such as various entity descriptions. This allowed attackers with permission to configure certain entities, such as credentials or agents, to specify crafted descriptions containing variable references. These would be replaced by the corresponding environment variable’s value during a subsequent import.

The export now adds ^ escape characters to exported strings as needed to prevent them from being interpolated during import. Previously exported configurations may require manual cleanup by Jenkins admins before being imported.

Configuration as Code Plugin exported secret values in plain text

SECURITY-1458 / CVE-2019-10363

Configuration as Code Plugin allows to export the current Jenkins configuration as a YAML file. Secrets such as passwords should be exported in their encrypted form to prevent accidental disclosure.

Configuration as Code Plugin did not reliably detect which values in the exported YAML file need to be considered sensitive (e.g. credentials and other secrets), as plugins could use the Secret type to store credentials encrypted on disk while not having the Secret type appear in their Java API. This resulted in credentials being exported in plain text in some cases.

Configuration as Code Plugin now inspects the type and looks for a field, getter, or constructor argument corresponding to the property, making the secret detection much more robust for the purpose of exporting encrypted secrets.

Amazon EC2 Plugin leaked beginning of private key in system log

SECURITY-673 / CVE-2019-10364

Amazon EC2 Plugin printed a log message that contained the beginning of the private key to the Jenkins system log.

The log message no longer includes the beginning of the private key.

Google Kubernetes Engine Plugin stored temporary secret in a user accessible location

SECURITY-1345 / CVE-2019-10365

Google Kubernetes Engine Plugin created a temporary file named .kube…config containing a temporary access token in the project workspace. This allowed the file to be accessed via workspace browsers, or accidentally archived, disclosing the token.

This temporary file is now created outside the regular project workspace.

Skytap Cloud CI Plugin stored credentials in plain text

SECURITY-1429 / CVE-2019-10366

Skytap Cloud CI Plugin stored credentials unencrypted in job config.xml files on the Jenkins controller. These credentials could be viewed by users with Extended Read permission, or access to the Jenkins controller file system.

Skytap Cloud CI Plugin now stores credentials encrypted.

Severity

Affected Versions

  • Amazon EC2 Plugin up to and including 1.43
  • Configuration as Code Plugin up to and including 1.24
  • Google Kubernetes Engine Plugin up to and including 0.6.2
  • Maven Integration Plugin up to and including 3.3
  • Maven Release Plug-in Plugin up to and including 0.14.0
  • Pipeline: Shared Groovy Libraries Plugin up to and including 2.14
  • Script Security Plugin up to and including 1.61
  • Skytap Cloud CI Plugin up to and including 2.06

Fix

  • Amazon EC2 Plugin should be updated to version 1.44
  • Configuration as Code Plugin should be updated to version 1.25
  • Google Kubernetes Engine Plugin should be updated to version 0.6.3
  • Maven Integration Plugin should be updated to version 3.4
  • Maven Release Plug-in Plugin should be updated to version 0.15.0
  • Pipeline: Shared Groovy Libraries Plugin should be updated to version 2.15
  • Script Security Plugin should be updated to version 1.62
  • Skytap Cloud CI Plugin should be updated to version 2.07

These versions include fixes to the vulnerabilities described above. All prior versions are considered to be affected by these vulnerabilities unless otherwise indicated.

Credit

The Jenkins project would like to thank the reporters for discovering and reporting these vulnerabilities:

  • Alex Earl (@alexcearl), Marvell Semiconductor, Inc., and Daniel Beck, CloudBees, Inc. for SECURITY-1422
  • Daniel Beck, CloudBees, Inc. for SECURITY-1184
  • David Fiser of Trend Micro Nebula working with Trend Micro's Zero Day Initiative for SECURITY-1429, SECURITY-1435
  • Jesse Glick, CloudBees, Inc. for SECURITY-713, SECURITY-1345
  • Mikaël Barbero (Eclipse Foundation) for SECURITY-1290
  • Oleg Nenashev, CloudBees, Inc. for SECURITY-1098
  • Wadeck Follonier, CloudBees, Inc. for SECURITY-1446