Popular open source automation server Jenkins has fixed multiple security vulnerabilities. The latest version changes how plug-ins use build parameters, though, so developers will need to adapt to the new process.
The vulnerabilities affect all previous releases, including the mainline releases up to and including 2.2, and LTS releases up to and including 1.651.1. Administrators should update their Jenkins installations to mainline release Jenkins 2.3 or LTS 1.651.2.
One of the vulnerabilities fixed in this release involves how build parameters in Jenkins are passed to write scripts as environmental variables. Depending on user access permissions and plug-ins on the Jenkins servers, malicious users would be able to trigger builds with arbitrary environment variables and modify the behavior of those builds, the Jenkins security advisory warned. In this situation, jobs could be defined with no parameters, but be built with parameters passed by the plug-ins. Parameters like PATH and DYLD_LIBRARY_PATH could be defined on jobs that didn't expect them, with unexpected results.
Instead of asking plug-in developers to pay attention to potential problems they may encounter, the team decided to update Jenkins to filter build parameters based on what's defined on the job, said R. Tyler Croy, Jenkins project board member and Community Evangelist at CloudBees, which sells a commercial Jenkins platform. Parameters that are not defined on the job are removed.
Developers have to change how they handle parameters in their plug-ins, such as not passing extra arguments and using the new method getAllParameters(), to adapt to this change. Instead of passing arguments, developers can define QueueAction for the metadata. The getAllParameters method returns all parameters and can be used by EnvironmentContributor extensions to add known safe parameters to build environments.
"I realize this change, among a few others that improve the security of Jenkins, may be difficult to adapt for some, but given the valuable secrets typically stored in Jenkins, I'm certain that this is the correct approach," wrote Daniel Beck, Jenkins software engineer.
The trade-off for fixing that bug within Jenkins was plug-ins that rely on the original behavior would break. Of the 1,100 or so plug-ins available for Jenkins, only four so far have been identified as affected by the update: Gerrit Trigger, GitHub pull request builder plug-in, Matrix Project Plug-in, and Release Plug-in. The GitHub plug-in passes a number of additional parameters describing the pull request.
Organizations can apply the updates, then reverse this specific fix to restore the original behavior by setting the system property hudson.model.ParametersAction.keepUndefinedParameters to true. For some environments, this step may be unsafe as the server will be vulnerable to attack.
Another option is to whitelist specific parameter names by setting hudson.model.ParametersAction.safeParameters to a comma-separated list of safe parameter names. The wiki page listing vulnerable plug-ins identifies the parameter names to be whitelisted.
To update or not to update
Administrators often have to decide between not updating or updating but breaking elements as a result. "The real question is, 'Are you going to fail closed or fail open?' If things break, could you be exposed to the world?" said Mark Curphey, founder and CEO of SourceClear, a software security startup. He also warned that builds that can be controlled by environment variables is "one of the many patterns that are quite pervasive in the developer tools ecosystem."
While still not ideal, the whitelisting approach is better than holding off on the update entirely, as it ensures other security fixes are applied. "We made sure to release this fix with the options described above, so that this change doesn't block updating those that rely on this behavior," wrote Beck.
The security update fixed a total of seven vulnerabilities, and only one affects plug-ins. If the organization doesn't use the parameters path in Jenkins, then they are unaffected and should apply the update.
Of the five medium-severity flaws, one affected plug-ins and two were information disclosure vulnerabilities. Permissions checks were missing from XML/JSON API endpoints providing information about installed plug-ins (CVE-2016-3723). Users with read-access permissions could determine which plug-ins and versions were installed on the endpoint. The other flaw leaked encrypted secures, such as passwords stored directly in the configuration, to users who had extended read access privileges (CVE-2016-3724). With the fix in the latest version, copying a job that contains secrets in the configuration now requires the job to have a Configure permission.
Some Jenkins URLs did not properly validate the redirect YRLs, letting users create URLs redirecting users to arbitrary scheme-relative URLs (CVE-2016-3726). And finally, an issue in the API URL /computer.(master)/api/xml allowed users with the Extended Read permission for the master node to see some global Jenkins configuration. After applying the update, trying to access that URL will now conditionally send "HTTP 400 Bad Request," the advisory said.
Two low-severity bugs were fixed in this release. One is an issue where any user with Jenkins access could download update site metadata because of a missing permissions check. The issue, combined with DNS cache poisoning, could disrupt Jenkins service, the advisory warned. The other is an issue where users with multiple accounts could prevent others from logging in (CVE-2016-3722) by changing the "full name" property. Full name was being resolved before the actual username in order to determine which account is trying to log in. The bug is low-severity because it would require a local attack.
"It's what you would do to prank or screw a co-worker," Croy said.
Considering the flaws are rated as either medium or low severity, it may be tempting to wait until the affected plug-ins are fixed before updating Jenkins. That is an option, but Croy said administrators have to assess the risks of not updating. The security profile for Jenkins that is Internet-facing is different from one used internally. A corporatewide Jenkins server may have a large number of users and a global reach, which can be a factor in deciding to update sooner rather later.
"We strongly recommend Jenkins installations on hostile networks to apply the update as soon as possible," Croy said.