Jenkins
Space shortcuts
Child pages
  • Plugins affected by fix for SECURITY-170
Create child page
Skip to end of metadata
Go to start of metadata

Background

In a May 2016 security advisory, a vulnerability was announced (SECURITY-170 / CVE-2016-3721) whereby attackers could potentially exploit the fact that certain Jenkins plugins allow the definition of arbitrary build parameters — which are in turn injected into the build envirionment.

The fix for this issue — which was first included in Jenkins versions 1.651.2 and Jenkins 2.3 — means that only build parameters that have been explicitly defined in a job's configuration will be available by default at build time. Any other arbitrary parameters added to a build by plugins will not be available by default.

As there are a number of plugins that rely on the behaviour in older Jenkins versions, upgrading to 1.651.2 or 2.3 means that certain build behaviours may be broken.

This page attempts to list the affected plugins, how the plugin behaves in current versions of Jenkins, and whether those plugins have been fixed to work with the new parameter filtering behaviour of Jenkins.

Workarounds

Note that there are a couple of global workarounds to either turn off the new parameter-filtering behaviour, or to whitelist certain parameter names, preventing them from being filtered out.

These are described in the security advisory and in the accompanying blog post.

Affected plugins

Note that this list is not exhaustive. If you encounter a plugin that no longer works as expected due to the fix for SECURITY-170, please add it to the list.
More importantly, please file a bug report, if one doesn't exist, to help ensure that the appropriate plugin maintainer is informed.

Some items here include a list of the parameter names that they use, which could be added to the whitelist mentioned in the "Workarounds" section above.

Plugin name

Behaviour

Issue

Status

Assembla Merge Request Builder Plugin

Parameters are stripped unless defined.

 Parameter names used


assemblaSourceSpaceId,assemblaAuthorName,assemblaDescription,assemblaSourceRepositoryUrl,assemblaTargetBranch,assemblaSourceRepositoryName,assemblaTargetRepositoryUrl,assemblaMergeRequestId,assemblaRefName,assemblaSourceBranch




















JENKINS-38254

PR - fixed in 1.1.4

CloudBees Docker Hub Notification

?

?

Fixed in 2.1.0 (fix)

Delivery Pipeline Plugin

PIPELINE_VERSION doesn't get created

JENKINS-34805

PR - fixed in 0.9.12

Gearman Plugin

Parameters are stripped unless defined. Should be made to autowhitelist.

JENKINS-34885

Not fixed

Gerrit Trigger

Builds fail with message "stderr: fatal: Couldn't find remote ref $GERRIT_REFSPEC"

 Parameter names used


GERRIT_EVENT_TYPE,GERRIT_EVENT_HASH,GERRIT_BRANCH,GERRIT_TOPIC,
GERRIT_CHANGE_NUMBER,GERRIT_CHANGE_ID,GERRIT_PATCHSET_NUMBER,
GERRIT_PATCHSET_REVISION,GERRIT_REFSPEC,GERRIT_PROJECT,GERRIT_CHANGE_SUBJECT,
GERRIT_CHANGE_COMMIT_MESSAGE,GERRIT_CHANGE_URL,GERRIT_CHANGE_OWNER,
GERRIT_CHANGE_OWNER_NAME,GERRIT_CHANGE_OWNER_EMAIL,
GERRIT_PATCHSET_UPLOADER,GERRIT_PATCHSET_UPLOADER_NAME

























































JENKINS-34753

PR - fixed in 2.21.0

GitHub Pull Request Builder Plugin

If using the standard ${sha1} branch spec, builds will fail with "Couldn't find any revision to build".
Pull requests remain in the "pending" state as the plugin fails to update the PR with the build outcome

 Parameter names used

ghprbActualCommit,ghprbActualCommitAuthor,ghprbActualCommitAuthorEmail,ghprbAuthorRepoGitUrl,
ghprbCommentBody,ghprbCredentialsId,ghprbGhRepository,ghprbPullAuthorEmail,ghprbPullAuthorLogin,
ghprbPullAuthorLoginMention,ghprbPullDescription,ghprbPullId,ghprbPullLink,
ghprbPullLongDescription,ghprbPullTitle,ghprbSourceBranch,ghprbTargetBranch,ghprbTriggerAuthor,
ghprbTriggerAuthorEmail,ghprbTriggerAuthorLogin,ghprbTriggerAuthorLoginMention,GIT_BRANCH,sha1

























































JENKINS-34762

Fixed in 1.32.3 (fix)
Fix removed from 1.32.2
Tentative fix in 1.32.1 (fix)

HP Application Automation Tools

HP_RUN_ID not available to subsequent build steps.

JENKINS-39654

Not fixed

Inheritance Plugin

Parameters defined on a `super` project are not expanded in a derived project

JENKINS-34831

Not fixed

Job Generator Plugin

Parameters aren't passed to child jobs

JENKINS-34814

Not fixed

Lockable Resources Plugin

Reserved resources variable name will not pass to the build

JENKINS-34853

PR - fixed in 1.9

Matrix Project Plugin

Parameters defined on a project are not passed to child jobs

JENKINS-34758

PR - fixed in 1.7

Parameterized Trigger Plugin

Parameters (e.g. when using properties files as source) are only passed if they are defined on the downstream job. This is the behavior intended by the SECURITY-170, see Jenkins Security Advisory 2016-05-11

n/a

Won't fix (hopefully)

Poll Mailbox Trigger Plugin

pmt_* job parameters are no longer injected into the job. e.g. pmt_from, pmt_replyTo, pmt_content, etc

#19

Fixed in 1.024 (fix)

Promoted Builds Plugin

Promoted builds do not receive parameter values defined at the job level

JENKINS-34826

Fixed in 2.27 (fix)

Release Plugin

Release parameters are not passed to the build

JENKINS-34996

PR - fixed in 2.6

Stash pullrequest builder plugin

Builds will fail with "Couldn't find any revision to build".
As this plugin accepts arbitrary parameters, it's one of the plugins that caused SECURITY-170.

 Parameter names used


pullRequestId,pullRequestTitle,sourceBranch,targetBranch,sourceRepositoryOwner,
sourceRepositoryName,destinationRepositoryOwner,destinationRepositoryName,
sourceCommitHash,destinationCommitHash

























































#84

Fixed in 1.7.0 - PR

P4 Plugin

Parameters generated for review builds are not passed.

 Parameter names used

json, review, change, status, pass,
fail, label, Submit





















































Note that there may be more missing parameters for other special build types.

JENKINS-35210

PR

M2 Release Plugin

SCM username and password environment variables, if configured, are not set

JENKINS-35261

Not fixed

Multijob Plugin (tikal-multijob-plugin)

see description in JENKINS-36124

JENKINS-36124

Fixed in 1.22 (fix)

Repository Connector Plugin

Artifact version chosen does not get set.

 

Not fixed. PR pending

Maven Metadata Plugin

The following parameters do not get passed on from parent to child jobs in Matrix Project Plugin. Version 1.7 (May 24, 2016)
 Version 1.7 broke the ability to pass these parameters to child jobs.JENKINS-34758 Parameters visibility in child builds (related to SECURITY-170)

MY_JAR_VERSION
MY_JAR_ARTIFACT_URL
MY_JAR_GROUP_ID
MY_JAR_ARTIFACT_ID
MY_JAR_CLASSIFIER
MY_JAR_PACKAGING

JENKINS-38978

Not fixed


6 Comments

  1. Alex Gray

    Whoa! I usually assume it's pretty safe going from one minor version of an LTS to another, but going from 1.651.1 to 1.652.2 COMPLETELY breaks all of our builds.

    Rather than saying "security fixes" in this update: https://jenkins.io/changelog-stable/, something along the lines in BOLD LETTERS:

    Upgrading to 1.652.2 COMPLETELY breaks your builds if you use the plugins listed on this page.

    1. Martin Weber

      Yes, having broken builds as a sudden is annoying.
      At least, the newest version gives you a chance to apply workarounds, it gives you a choice.

      But what, if your Jenkins instance starts to produce end-user install packages containing viruses/trojans/ransomware and these get delivered? I would not call that annoying.

  2. Tommy Tynjä

    Where do you find the parent org.jenkins-ci.plugins:plugin artifact with version corresponding to 1.651.2 which contains the security fix? I can't find it when looking through https://maven-repository.com/artifact/org.jenkins-ci.plugins?page=20.

  3. B Hicks

    So on this page, https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+2016-05-11,  you claim that a workaround can be put in place to revert back to old behavior. You even mention what needs to be changed to do so: "it's possible to restore the previous behavior by setting the system property hudson.model.ParametersAction.keepUndefinedParameters to true." But do you explain where to make that change? Nope, not a chance. Now I have to look into restoring the VM which my Jenkins server runs on so I can get Jenkins back to the version before this upgrade AND I have to look into alternatives to the Jenkins server. Thanks, really. Thank you very much.

    Edit: I found where to make this modification on a Windows server running Jenkins as a service. By default Jenkins installs to C:\Program Files (x86)\Jenkins, so open that directory, then open jenkins.xml. It should be fairly obvious as this text file is small, but somewhere around lines 40-41 should be the <arguments> string which is passed to java.exe to start & run Jenkins. 

    Example from jenkins.xml:

    Original: <arguments>-Xrs -Xmx256m -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -jar "%BASE%\jenkins.war" --httpPort=-1 --httpsPort=443 </arguments>

    Modified: <arguments>-Xrs -Xmx256m -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -Dhudson.model.ParametersAction.keepUndefinedParameters=true -jar "%BASE%\jenkins.war" --httpPort=-1 --httpsPort=443 </arguments>

  4. Michael Andrews

    Yeah - this took us down for 24 hours. Frustrating. Took us a while to find the issue. Also, keepUndefinedParameters=true did not work for us. Ended up rolling back. This was a bad one.

  5. Jim Klimov

    We use a https://github.com/jenkinsci/stash-pullrequest-builder-plugin/ successfully (it works), with a build somewhat newer than the official Git head (so including the fix above for 1.7.0), however error messages are logged about passing variables into the build which are not the job's official build arguments. As one corollary, we also can not quickly "Rebuild with Arguments" the same job setup, though in case of this plugin it is just an annoyance - rescheduling a PR build goes via posting comments to the PR in Stash.

    In fact, there still was a practical problem: those warnings swamped our Jenkins master log partition on one occasion faster than the logs were rotated away, causing a server outage, so then we've seen them and set an appropriate `-Dhudson.model.ParametersAction....` into the configuration (`/etc/sysconfig/jenkins` in our Unix/Linux case).

Write a comment…