Jenkins Security Advisory 2013-02-16

Skip to end of metadata
Go to start of metadata

This advisory announces multiple security vulnerabilities that were found in Jenkins core.

Description

One of the vulnerabilities allows cross-site request forgery (CSRF) attacks on Jenkins master, which causes an user to make unwanted actions on Jenkins. Another vulnerability enables cross-site scripting (XSS) attacks, which has the similar consequence. Another vulnerability allowed an attacker to bypass the CSRF protection mechanism in place, thereby mounting more CSRF attackes. These attacks allow an attacker without direct access to Jenkins to mount an attack.

In the fourth vulnerability, a malicious user of Jenkins can trick Jenkins into building jobs that he does not have direct access to.

And lastly, a vulnerability allows a malicious user of Jenkins to mount a denial of service attack by feeding a carefully crafted payload to Jenkins.

Severity

The first three vulnerabilities (CSRF and XSS) are rated as high, as they allow malicious users to gain unauthorized access to the information and impersonate the administrator of the system. In addition, this allows Jenkins inside a firewall to be attacked from outside. On the other hands, this attack can be only mounted passively, and the attacker needs to know the URL of your Jenkins installations.

The build privilege escalation vulnerability is rated as medium, as it requires an attacker to be a valid user of Jenkins with a write access.

The last denial of service attack is rated low, as it also requires an attacker to be a valid user of Jenkins with a write access, and this does not result in any data loss nor privilege escalation.

Fix

  • Main line users should upgrade to Jenkins 1.502
  • LTS users should upgrade to 1.480.3

All the prior versions are affected by these vulnerabilities.

As a part of the fix, these versions contain the following incompatible changes. Administrators of Jenkins need to be aware of the following implications of the upgrade:

  • JSONP support in Remote access API is removed. If you have other programs that depend on this behavior, you can set the hudson.model.Api.INSECURE system property to true to resurrect behaviour. However, this is highly discouraged.
  • If your Jenkins does not have the security enabled, some of the Remote access API calls that previously didn't require POST now requires it. See the "CSRF Protection" section of the remote access API page for how to add necessary header.

Other resources

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.