Jenkins Security Advisory 2018-02-05

Multiple plugins based on Static Analysis Utilities plugin are affected by an XML External Entity (XXE) processing vulnerability. This allows an attacker to configure build processes such that one of these plugins parses a maliciously crafted file that uses external entities for extraction of secrets from the Jenkins controller, server-side request forgery, or denial-of-service attacks.

External entity resolution has been disabled for these plugins.

SECURITY-521 / CVE-2018-1000056

JUnit plugin is affected by an XML External Entity (XXE) processing vulnerability. This allows an attacker to configure build processes such that JUnit plugin parses a maliciously crafted file that uses external entities for extraction of secrets from the Jenkins controller, server-side request forgery, or denial-of-service attacks.

External entity resolution has been adjusted to avoid XXE and still satisfy the existing features.

SECURITY-698 / CVE-2018-1000057

Credentials Binding plugin allows specifying passwords and other secrets as environment variables, and will hide them from console output in builds.

However, since Jenkins will try to resolve references to other environment variables in environment variables passed to a build, this can result in other values than the one specified being provided to a build. For example, the value p4$$w0rd would result in Jenkins passing on p4$w0rd, as $$ is the escape sequence for a single $.

Credentials Binding plugin does not prevent such a transformed value (e.g. p4$w0rd) from being shown on the build log, allowing users to reconstruct the actual password value from the transformed one.

Credentials Binding plugin will now escape any $ characters in password values so they are correctly passed to the build.

This issue did apply to freestyle and other classic job types, but does not apply to Pipelines.

SECURITY-699 / CVE-2018-1000058

Pipelines are subject to script security: Either the entire Pipeline needs to be approved, or it runs in a sandbox, with only approved methods etc. allowed to be called.

Methods related to Java deserialization like readResolve implemented in Pipeline scripts were not subject to sandbox protection, and could therefore execute arbitrary code. This could be exploited e.g. by regular Jenkins users with the permission to configure Pipelines in Jenkins, or by trusted committers to repositories containing Jenkinsfiles.

Deserialization of objects in Pipeline is now also subject to sandbox protection.

This change may cause existing scripts relying on the incomplete sandbox protection to start failing, and requiring additional script approval.