Jenkins Security Advisory 2019-06-11

Token Macro Plugin did not configure its XML parser in a way that would prevent XML External Entity (XXE) processing.

This allowed attackers able to control the contents of files processed with the ${XML} macro to have Jenkins parse a maliciously crafted XML file that uses external entities for extraction of secrets from the Jenkins agent, server-side request forgery, or denial-of-service attacks.

Token Macro Plugin no longer processes XML External Entities in XML documents.

jx-resources Plugin did not perform permission checks on a method implementing form validation. This allowed users with Overall/Read access to Jenkins to connect to an attacker-specified Kubernetes server and obtain information about an attacker-specified namespace. Doing so might also leak service account credentials used for the connection. Additionally, it allowed attackers to obtain the value of any attacker-specified environment variable for the Jenkins controller process.

Additionally, this form validation method did not require POST requests, resulting in a cross-site request forgery vulnerability.

This form validation method now requires POST requests and Overall/Administer permissions.

A missing permission check in a form validation method in CloudBees CD Plugin allowed users with Overall/Read permission to initiate a connection test to an attacker-specified server with attacker-specified username and password.

Additionally, the form validation method did not require POST requests, resulting in a CSRF vulnerability.

This form validation method now requires POST requests and Overall/Administer permissions.

Various form validation and form autocompletion methods in CloudBees CD Plugin lacked permission checks. This allowed attackers with Overall/Read access to obtain information about the configuration of CloudBees CD Plugin, as well as the configuration and data of connected ElectricFlow servers.

These form validation and autocompletion methods now require Overall/Administer or Job/Configure permission, as appropriate for the given method.

CloudBees CD Plugin unconditionally disabled SSL/TLS certificate validation for the entire Jenkins controller JVM during the deployment/publication of an application.

CloudBees CD Plugin no longer does that. Instead, the existing opt-in option to ignore SSL/TLS errors is used during deployment for the specific connection.

This issue was caused by an incomplete fix for SECURITY-937.

The plugin adds metadata displayed on build pages during its operations.

Any user content was not escaped, resulting in a cross-site scripting vulnerability allowing users with Job/Configure permission, or attackers controlling API responses received from ElectricFlow to render arbitrary HTML and JavaScript on Jenkins build pages.

Build metadata is now filtered through a HTML formatter that only allows showing basic HTML, neutralizing any unsafe data. Additionally, all builds executed after the security update is applied will now properly escape content received from ElectricFlow.

The configuration forms of various post-build steps contributed by CloudBees CD Plugin were vulnerable to cross-site scripting.

This allowed attackers able to control the output of connected ElectricFlow servers' APIs to inject arbitrary HTML and JavaScript into the configuration form.

CloudBees CD Plugin no longer interprets HTML/JavaScript in responses from ElectricFlow server APIs on job configuration forms.