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 scheme. 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 actions. 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 whole. 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 fashion. 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 Resolution ========== 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.  https://www.djangoproject.com/security/
Grabbing this one to do.
Assignee: nobody → willkg
deployed to prod
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
These bugs are all resolved, so I'm removing the security flag from them.
You need to log in before you can comment on or make changes to this bug.