Anon remote HTTP access to jenkins cryptographic master key

[James Page]

https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+2013-01-04

This vulnerability allows 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, as well as the 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

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.

[James Page (james-page)]

I'm working on getting the new version of Jenkins into Debian experimental which will fix the issue for raring; cherry picks for the other three releases will follow.

[James Page (james-page)]

The backport's of the cherry picks to resolve this issue are proving hard as the part of jenkins they effect has changed significantly.

Upstream are looking at a backport to 1.424.x branch as well.

[Jamie Strandboge (jdstrand)]

Thank you for reporting this bug to Ubuntu. oneiric has reached EOL
(End of Life) and is no longer supported. As a result, this bug
against oneiric is being marked "Won't Fix". Please see
https://wiki.ubuntu.com/Releases for currently supported Ubuntu
releases.

Please feel free to report any other bugs you may find.

[Steve Langasek (vorlon)]

The Precise Pangolin has reached end of life, so this bug will not be fixed for that release