This advisory announces vulnerabilities in the following Jenkins deliverables:
A form action method in GitHub Plugin did not check the permission of the user accessing it, allowing anyone with Overall/Read access to Jenkins to cause Jenkins to send a GitHub API request to create an API token to an attacker-specified URL.
This allowed users with Overall/Read access to Jenkins to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins.
Additionally, this form validation method did not require POST requests, resulting in a CSRF vulnerability.
The form validation method now requires POST requests and the Overall/Administer permission.
SSH Credentials Plugin allowed the creation of SSH credentials with keys "From a file on Jenkins controller". Credentials Binding Plugin 1.13 and newer allows binding SSH credentials to environment variables. In combination, these two features allow users with the permission to configure a job to read arbitrary files on the Jenkins controller by creating an SSH credential referencing an arbitrary file on the Jenkins controller, and binding it to an environment variable in a job.
SSH Credentials Plugin no longer supports SSH credentials from files on the Jenkins controller file system, neither user-specified file paths nor ~/.ssh.
Existing SSH credentials of these kinds are migrated to "directly entered" SSH credentials.
|
Note
|
If Blue Ocean is installed, it needs to be updated to 1.5.1 or 1.6.1, or the creation of pipelines for plain Git will not work anymore after installing the fix for this issue. |
SAML Plugin did not invalidate the previous session and create a new one upon successful login, allowing attackers able to control or obtain another user’s pre-login session ID to impersonate them.
SAML Plugin now invalidates the previous session during login and creates a new one.
Openstack Cloud Plugin did not perform permission checks on methods implementing form validation. This allowed users with Overall/Read access to Jenkins to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins, and to cause Jenkins to submit HTTP requests to attacker-specified URLs.
Additionally, these form validation methods did not require POST requests, resulting in a CSRF vulnerability.
These form validation methods now require POST requests and Overall/Administer permissions.
AWS CodeDeploy Plugin could persist environment variables from the last run of any project with the post-build step configured in the job’s config.xml file.
In some cases, this allowed users with file system access or Extended Read permission to obtain those potentially sensitive environment variables by accessing the project’s config.xml.
AWS CodeDeploy Plugin 1.20 and newer no longer stores build environment variables on disk.
Existing job config.xml will retain the stored environment variables until the job configuration is saved again.
AWS CodeDeploy Plugin stored the AWS Secret Key in its configuration unencrypted in jobs' config.xml files and its global configuration file on the Jenkins controller.
This key could be viewed by users with Extended Read permission, or access to the Jenkins controller file system.
While masked from view using a password form field, the AWS Secret Key was transferred in plain text to users when accessing the job configuration form.
AWS CodeDeploy Plugin 1.20 and newer stores the AWS Secret Key encrypted in the configuration files on disk and no longer transfers it to users viewing the configuration form in plain text. Existing jobs need to have their configuration saved for existing plain text secret keys to be overwritten.
AWS CodeBuild Plugin stored the AWS Secret Key in its configuration unencrypted in jobs' config.xml files on the Jenkins controller.
This key could be viewed by users with Extended Read permission, or access to the Jenkins controller file system.
While masked from view using a password form field, the AWS Secret Key was transferred in plain text to users when accessing the job configuration form.
AWS CodeBuild Plugin 0.27 and newer stores the AWS Secret Key encrypted in the configuration file on disk and no longer transfers it to users viewing the configuration form in plain text. Existing jobs need to have their configuration saved for existing plain text secret keys to be overwritten.
AWS CodePipeline Plugin stored the AWS Secret Key in its configuration unencrypted in jobs' config.xml files on the Jenkins controller.
This key could be viewed by users with Extended Read permission, or access to the Jenkins controller file system.
While masked from view using a password form field, the AWS Secret Key was transferred in plain text to users when accessing the job configuration form.
AWS CodePipeline Plugin 0.37 and newer stores the AWS Secret Key encrypted in the configuration file on disk and no longer transfers it to users viewing the configuration form in plain text. Existing jobs need to have their configuration saved for existing plain text secret keys to be overwritten.
Badge Plugin stored and displayed user-provided HTML for badges and summaries unprocessed, allowing users with the ability to control badge content to store malicious HTML to be displayed within Jenkins.
Badge Plugin 1.5 and newer sanitizes the provided HTML for display on the Jenkins web UI.
CollabNet Plugin disabled SSL/TLS certificate validation for the entire Jenkins controller JVM by default.
CollabNet Plugin 2.0.5 and newer no longer does that.
It instead requires users to opt in to disabling SSL/TLS certificate validation by setting the system property hudson.plugins.collabnet.CollabNetPlugin.skipSslValidation to true.
This feature applies to connections by this plugin only.
A form validation method in URLTrigger Plugin did not check the permission of the user accessing them, allowing anyone with Overall/Read access to Jenkins to cause Jenkins to send a GET request to a specified URL.
Additionally, this form validation method did not require POST requests, resulting in a CSRF vulnerability.
This form validation method now no longer connects to a user provided URL.
Fortify CloudScan Plugin did not validate file names in rulepack ZIP archives it extracts, resulting in an arbitrary file write vulnerability.
Fortify CloudScan Plugin 1.5.2 and newer rejects relative paths escaping the ZIP extraction base directory.
IBM z/OS Connector Plugin did not encrypt password credentials stored in its configuration. This could be used by users with Jenkins controller file system access to obtain the password.
While masked from view using a password form field, the AWS Secret Key was transferred in plain text to administrators when accessing the global configuration form.
IBM z/OS Connector Plugin 2.0.0 and newer integrates with Credentials Plugin, no longer storing credentials itself.
Configuration as Code Plugin lacked a permission check in the method handling the URL exporting the system configuration. This allowed users with Overall/Read access to Jenkins to obtain this YAML export.
This permission check has been added in Configuration as Code Plugin 0.8-alpha.
Configuration as Code Plugin logged secrets set via its configuration to the Jenkins controller system log in plain text. This allowed users with access to the Jenkins log files to obtain these passwords and similar secrets.
Secrets are now masked when logging configuration.
These versions include fixes to the vulnerabilities described above. All prior versions are considered to be affected by these vulnerabilities unless otherwise indicated.
The Jenkins project would like to thank the reporters for discovering and reporting these vulnerabilities: