Anon remote HTTP access to jenkins cryptographic master key

Bug #1098114 reported by James Page on 2013-01-10
260
This bug affects 1 person
Affects Status Importance Assigned to Milestone
jenkins (Debian)
Fix Released
Unknown
jenkins (Ubuntu)
Critical
Unassigned
Oneiric
Critical
Unassigned
Precise
Critical
Unassigned
Quantal
Critical
Unassigned
Raring
Critical
Unassigned

Bug Description

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.

CVE References

James Page (james-page) on 2013-01-10
information type: Public → Public Security
summary: - Anon remote HTTP access to jenkins cryptographic maseter key
+ Anon remote HTTP access to jenkins cryptographic master key
James Page (james-page) on 2013-01-10
Changed in jenkins (Ubuntu Oneiric):
importance: Undecided → Critical
Changed in jenkins (Ubuntu Precise):
importance: Undecided → Critical
Changed in jenkins (Ubuntu Quantal):
importance: Undecided → Critical
Changed in jenkins (Ubuntu Raring):
importance: Undecided → Critical
James Page (james-page) wrote :

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.

Changed in jenkins (Debian):
status: Unknown → Fix Released
James Page (james-page) on 2013-01-10
Changed in jenkins (Ubuntu Raring):
status: New → Fix Released
James Page (james-page) wrote :

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.

Changed in jenkins (Debian):
status: Fix Released → New
Jamie Strandboge (jdstrand) wrote :

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.

Changed in jenkins (Ubuntu Oneiric):
status: New → Won't Fix
Changed in jenkins (Debian):
status: New → Fix Released
Changed in jenkins (Ubuntu Quantal):
status: New → Won't Fix
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.