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 |
---|---|---|---|
Parameters are stripped unless defined. |
PR - fixed in 1.1.4 |
||
? |
? |
Fixed in 2.1.0 (fix) |
|
PIPELINE_VERSION doesn't get created |
PR - fixed in 0.9.12 |
||
Parameters are stripped unless defined. Should be made to autowhitelist. |
Not fixed |
||
Builds fail with message "stderr: fatal: Couldn't find remote ref $GERRIT_REFSPEC" |
PR - fixed in 2.21.0 |
||
If using the standard |
Fixed in 1.32.3 (fix) |
||
HP_RUN_ID not available to subsequent build steps. |
Not fixed |
||
Parameters defined on a `super` project are not expanded in a derived project |
Not fixed |
||
Parameters aren't passed to child jobs |
Not fixed |
||
Reserved resources variable name will not pass to the build |
PR - fixed in 1.9 |
||
Parameters defined on a project are not passed to child jobs |
PR - fixed in 1.7 |
||
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) |
|
pmt_* job parameters are no longer injected into the job. e.g. pmt_from, pmt_replyTo, pmt_content, etc |
Fixed in 1.024 (fix) |
||
Promoted builds do not receive parameter values defined at the job level |
Fixed in 2.27 (fix) |
||
Release parameters are not passed to the build |
PR - fixed in 2.6 |
||
Builds will fail with "Couldn't find any revision to build". |
Fixed in 1.7.0 - PR |
||
Parameters generated for review builds are not passed. Note that there may be more missing parameters for other special build types. |
|||
SCM username and password environment variables, if configured, are not set |
Not fixed |
||
see description in JENKINS-36124 |
Fixed in 1.22 (fix) |
||
Artifact version chosen does not get set. |
|
Not fixed. PR pending |
|
The following parameters do not get passed on from parent to child jobs in Matrix Project Plugin. Version 1.7 (May 24, 2016) |
Not fixed |
6 Comments
Unknown User (grayaii)
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.
Unknown User (15knots)
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.
Unknown User (tommysdk)
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.
Unknown User (bhicks)
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
totrue
." 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>
Unknown User (killdash9)
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.
Unknown User (jimklimov)
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).