Jenkins Security Advisory 2018-12-05

Jenkins uses the Stapler web framework for HTTP request handling. Stapler’s basic premise is that it uses reflective access to code elements matching its naming conventions. For example, any public method whose name starts with get, and that has a String, int, long, or no argument can be invoked this way on objects that are reachable through these means. As these naming conventions closely match common code patterns in Java, accessing crafted URLs could invoke methods never intended to be invoked this way.

As of publication of this advisory, we are aware of the following potential attacks in the latest Jenkins releases that do not yet contain this fix:

The previous two Jenkins security updates, LTS 2.121.3 and 2.138, as well as Jenkins LTS 2.138.2 and 2.146 included changes that prevent a number of other attacks resulting from this vulnerability. The following is a selection of attacks that were discovered during fix development, and are already being prevented on current releases of Jenkins:

Given the vast potential attack surface, we fully expect other attacks, that we are not currently aware of, to be possible on Jenkins releases that do not have this fix applied. This is reflected in the high score we assigned to this issue, rather than limiting the score to the impact through known issues.

The Stapler web framework has been extended with a Service Provider Interface (SPI) that allows methods and fields to be excluded from routing. The implementation of that SPI in Jenkins now restricts which getter methods, do* action methods, and fields can be invoked reflectively by Stapler. Further details are available in the developer documentation:

The fix for SECURITY-499 introduced a mechanism that renamed user directories on disk as a user with an unsafe user name (user ID) is loaded. Insufficient input validation allowed attackers to rename such user directories even for users with a safe user name by submitting a crafted user name when attempting to log in, even with an invalid password. Doing so prevented users from logging in successfully afterwards.

Jenkins no longer uses directory names as a reference for user names, making the on-load migration of user records unnecessary. Instead, the new file users/users.xml is used to map user names to the directories containing the user metadata.

On the first startup after updating Jenkins to a version containing this fix, existing legacy user directories are migrated. For further advice related to this user record migration, see the LTS upgrade guide.

The file browser for workspaces, archived artifacts, and $JENKINS_HOME/userContent/ followed symbolic links to locations outside the directory being browsed.

While builds typically have access to the file system outside the workspace allocated by Jenkins, this should not extend to beyond the execution of a build on that agent. Notably, the configuration may have been changed to not allow a build to run on a given agent, but the workspace used during the previous execution still exists, and could allow browsing the file system outside the workspace.

Neither browsing through the UI nor downloading directory content as a ZIP file allow accessing directories and files outside the workspace anymore.

In rare cases, it may be desirable to disable this fix. To do so, set the Java system property hudson.model.DirectoryBrowserSupport.allowSymlinkEscape to true. Learn more about system properties in Jenkins.

The form validation for cron expressions (e.g. "Poll SCM", "Build periodically") could enter infinite loops when cron expressions only matching certain rare dates were entered, blocking request handling threads indefinitely.