Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Jenkins security patches could break plug-ins

Fahmida Y. Rashid | June 30, 2016
The latest security update for Jenkins changed how build parameters are handled, impacting multiple plug-ins

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.


Previous Page  1  2  3  Next Page 

Sign up for CIO Asia eNewsletters.