Closed Bug 1053863 Opened 7 years ago Closed 7 years ago

django 1.4.14/1.5.9/1.6.6 security update (Input)


(Input :: General, defect)

Not set


(Not tracked)



(Reporter: willkg, Assigned: willkg)


On Wednesday, August 20th, 2014, the Django project will be issuing a set  of releases to remedy security issues reported. This bug contains descriptions of the issues and descriptions of the changes which will be made to Django.

Please read the entirety of this bug.

If these issues apply to your project, update Django for your project on Wednesday, then mark the bug FIXED.

If you're sure these issues do not apply to your project, please close this out with a WONTFIX and an explanation of why each of these don't apply to your project.

The rest of this bug is directly from the security bulletin.

Issue: reverse() can generate URLs pointing to other hosts

Django includes the helper function
``django.core.urlresolvers.reverse``, typically used to generate a URL
from a reference to a view function or URL pattern name. However, when
presented with input beginning with two forward-slash characters
(``//``), ``reverse()`` could generate scheme-relative URLs to other
hosts, allowing an attacker who is aware of unsafe use of
``reverse()`` (i.e., in a situation where an end user can control the
target of a redirect, to take a common example) to generate links to
sites of their choice, enabling phishing and other attacks.

To remedy this, URL reversing now ensures that no URL starts with two
slashes (``//``), replacing the second slash with its URL encoded
counterpart (``%2F``). This approach ensures that semantics stay the
same, while making the URL relative to the domain and not to the

Issue: file upload denial of service

In the default configuration, when Django's file upload handling
system is presented with a file that would have the same on-disk path
and name as an existing file, attempts to generate a new unique
filename by appending an underscore and an integer to the end of the
(as stored on disk) filename, incrementing the integer (i.e., ``_1``,
``_2``, etc.) until it has generated a name which does not conflict
with any existing file.

An attacker with knowledge of this can exploit the sequential behavior
of filename generation by uploading many tiny files which all share a
filename; Django will, in processing them, generate ever-increasing
numbers of ``os.stat()`` calls as it attempts to generate a unique
filename. As a result, even a relatively small number of such uploads
can significantly degrade performance.

To remedy this, Django's file-upload system will no longer use
sequential integer names to avoid filename conflicts on disk; instead,
a short random alphanumeric string will be appended, removing the
ability to reliably generate many repeatedly-conflicting filenames.

Issue: RemoteUserMiddleware session hijacking

Django provides a middleware --
``django.contrib.auth.middleware.RemoteUserMiddleware`` -- and an
authentication backend,
``django.contrib.auth.backends.RemoteUserBackend``, which use the
``REMOTE_USER`` header for authentication purposes.

In some circumstances, use of this middleware and backend could result
in one user receiving another user's session, if a change to the
``REMOTE_USER`` header occurred without corresponding logout/login

To remedy this, the middleware will now ensure that a change to
``REMOTE_USER`` without an explicit logout will force a logout and
subsequent login prior to accepting the new ``REMOTE_USER``.

Issue: data leakage via querystring manipulation in admin

Django's administrative interface, ``django.contrib.admin``, offers a
feature whereby related objects can be displayed for selection in a
popup window. The mechanism for this relies on placing values in the
URL and querystring which specify the related model to display and the
field through which the relationship is implemented. This mechanism
does perform permission checks at the level of the model class as a

This mechanism did not, however, verify that the specified field
actually represents a relationship between models. Thus a user with
access to the admin interface, and with sufficient knowledge of model
structure and the appropriate URLs, could constructed popup views
which would display the values of non-relationship fields, including
fields the application developer had not intended to expose in such a

To remedy this, the admin interface will now, in addition to its
normal permission checks, verify that the specified field does indeed
represent a relationship, to a model registered with the admin, and
will raise an exception if either condition is not true.

Affected versions

* Django master development branch (currently at pre-alpha status)

* Django 1.7 (currently at release-candidate status)

* Django 1.6

* Django 1.5

* Django 1.4


Included with this email are patches for each of the above issues;
each attached compressed archive file is named according to its
corresponding issue, and contains the patches for that issue for each
affected version of Django.

These patches will be applied to the Django development repository on
Wednesday, August 20, 2014, and the following releases will be issued
along with disclosure of the above issues:

* Django 1.7 release candidate 3

* Django 1.6.6

* Django 1.5.9

* Django 1.4.14

As Django 1.7 is currently in a release candidate state, and Django's
master development branch is in a pre-alpha state, users are strongly
encouraged not to run production deployments from them; the disclosure
announcement will nonetheless include a reminder of this and encourage
any such users to upgrade immediately.

Assignee: nobody → willkg
Landed in master:

Pushed to prod just now.
Closed: 7 years ago
Resolution: --- → FIXED
These bugs are all resolved, so I'm removing the security flag from them.
Group: websites-security
You need to log in before you can comment on or make changes to this bug.