Jenkins Security Advisory 2019-07-31

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 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.

Pipeline: Deprecated 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: Deprecated Groovy Libraries Plugin now performs the appropriate permission check.

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.

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.

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 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 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 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 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 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 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 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 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 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.