Security releases issued
Today the Django team is issuing multiple releases -- Django 1.4.13, Django 1.5.8, Django 1.6.5 and Django 1.7 beta 4 -- as part of our security process. These releases are now available on PyPI and our download page.
These releases address a caching issue which might lead to cache poisoning and an incorrect validation of safe redirect targets. Since these issues will affect the majority of users we strongly encourage everyone to upgrade.
For more details, read on.
Issue: Caches may be allowed to store and serve private data (CVE-2014-1418)
In certain situations, Django may allow caches to store private data related to a particular session and then serve that data to requests with a different session, or no session at all. This can both lead to information disclosure, and can be a vector for cache poisoning.
When using Django sessions, Django will set a Vary: Cookie header to ensure caches do not serve cached data to requests from other sessions. However, older versions of Internet Explorer (most likely only Internet Explorer 6, and Internet Explorer 7 if run on Windows XP or Windows Server 2003) are unable to handle the Vary header in combination with many content types. Therefore, Django would remove the header if the request was made by Internet Explorer.
To remedy this, the special behavior for these older Internet Explorer versions has been removed, and the Vary header is no longer stripped from the response. In addition, modifications to the Cache-Control header for all Internet Explorer requests with a Content-Disposition header, have also been removed as they were found to have similar issues.
Thanks to Seth Arnold at Canonical for reporting this issue to us, and to Michael Nelson, Natalia Bidart, James Westby for discovering the issue and reporting it to Canonical.
Issue: Malformed URLs from user input incorrectly validated (CVE-2014-3730)
The validation for redirects did not correctly validate some malformed URLs, which are accepted by some browsers. This allows a user to be redirected to an unsafe URL unexpectedly.
Django relies on user input in some cases (e.g. django.contrib.auth.views.login, django.contrib.comments, and i18n) to redirect the user to an "on success" URL. The security checks for these redirects (namely django.util.http.is_safe_url()) did not correctly validate some malformed URLs, such as http:\\\djangoproject.com, which are accepted by some browsers with more liberal URL parsing.
To remedy this, the validation in is_safe_url() has been tightened to be able to handle and correctly validate these malformed URLs.
Thanks to Peter Kuma and Gavin Wahl for reporting this issue to us.
- Django master development branch
- Django 1.7 (currently at beta status)
- Django 1.6
- Django 1.5
- Django 1.4
Patches have been applied to Django's master development branch, and to the 1.4, 1.5, 1.6 and 1.7 release branches, which resolve the issues described above. The patches may be obtained directly from the following changesets:
On the development master branch:
On the Django 1.7 release branch:
On the Django 1.6 release branch:
On the Django 1.5 release branch:
On the Django 1.4 release branch:
The following new releases have been issued:
General notes regarding security reporting
As always, we ask that potential security issues be reported via private email to email@example.com, and not via Django's Trac instance or the django-developers list. Please see our security policies for further information.
UPDATE: 09:12 UTC 15.05.2014 - Added CVE for is_safe_url