Jenkins Security Advisory 2013-01-04
This advisory announces a security vulnerability that was found in the Jenkins core.
This vulnerability allows an attacker with an HTTP access to the server to retrieve the master cryptographic key of Jenkins. This key is used to encrypt sensitive data in configuration files under $JENKINS_HOME and in the HTML forms, authenticate slaves connecting to the master, and authenticate REST API access from users.
An attacker can then use this master cryptographic key to mount remote code execution attack against the Jenkins master, or impersonate arbitrary users in making REST API calls.
There are several factors that mitigate some of these problems that may apply to specific installations.
The particular attack vector is only applicable on Jenkins instances that have slaves attached to them, and allow anonymous read access.
Jenkins allows users to re-generate the API tokens. Those re-generated API tokens cannot be impersonated by the attacker.
This vulnerability is rated as critical as it can be mounted by an anonymous user, and a compromised system allows remote code execution.
- Main line users should upgrade to Jenkins 1.498
- LTS users should upgrade to 1.480.2
- Users of Jenkins Enterprise by CloudBees 1.447.x should upgrade to 1.447.6.1
- Users of Jenkins Enterprise by CloudBees 1.466.x should upgrade to 1.466.12.1
- Fix has already been deployed to DEV@cloud
All the prior versions are affected by these vulnerabilities.
These new versions generate a new set of different cryptographic keys to protect sensitive data, authenticate slaves, and so on. Because of this, administrators of Jenkins need to be aware of the following implications of the upgrade:
- API tokens of many users will likely change as a result, and therefore if you have scripts and external programs that rely on these tokens, some of them will fail. Please retrieve the updated API tokens from the UI.
- Slaves that are started via Java Web Start will fail to reconnect if the *.jnlp file is locally stored. This is because the authentication tokens change. An administrator would have to login to the UI, retrieve the *.jnlp file and overwrite what’s already on the slave. A slave that was launched via Java Web Start and then turned into a service through its menu falls into this category.
- Once the new version is started, the administrator needs to run the Re-keying process to update the on-disk configuration files to use the newer encryption key. Go to “Manage Jenkins” page and follow the instruction at the top of the page. Also make sure to read the Wiki page to understand more about this process.