Closed Bug 996918 Opened 11 years ago Closed 11 years ago

django 1.4.11/1.5.6/1.6.3 security update (Input)

Categories

(Input :: General, defect, P1)

defect

Tracking

(Not tracked)

RESOLVED FIXED
2014Q2

People

(Reporter: willkg, Assigned: willkg)

Details

(Whiteboard: u=dev c=general p=1 s=input.2014q2)

On Monday, April 21, 2014, the Django project will be issuing a set of releases to remedy security issues reported. This bug contains descriptions of the issues, descriptions of the changes which will be made to Django, and the patches which will be applied to Django. Please read the entirety of this bug, figure out whether it applies to your project and update on Monday accordingly. Then mark the bug FIXED. If you're sure it does 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: Unexpected code execution using ``reverse()`` ==================================================== Django's URL handling is based on a mapping of regex patterns (representing the URLs) to callable views, and Django's own processing consists of matching a requested URL against those patterns to determine the appropriate view to invoke. Django also provides a convenience function -- ``django.core.urlresolvers.reverse()`` -- which performs this process in the opposite direction. The ``reverse()`` function takes information about a view, and returns a URL which would invoke that view. Use of ``reverse()`` is encouraged for application developers, as the output of ``reverse()`` is always based on the current URL patterns, meaning developers do not need to change other code when making changes to URLs. One argument signature for ``reverse()`` is to pass a dotted Python path to the desired view. In this situation, Django will import the module indicated by that dotted path as part of generating the rsulting URL. If such a module has import-time side effects, those side effects will occur. Thus it is possible for an attacker to cause unexpected code execution, given the following conditions: 1. One or more views are present which construct a URL based on user input (commonly, a "next" parameter in a querystring indicating where to redirect upon successful completion of an action). 2. One or more modules known to an attacker to exist on the server's Python import path, which perform code execution with side effects on importing. To remedy this, ``reverse()`` will now only accept and import dotted paths based on the view-containing modules listed in the project's URL pattern configuration, so as to ensure that only modules the developer intended to be imported in this fashion can or will be imported. Issue: Caching of anonymous pages could reveal CSRF token ========================================================= Django includes both a caching framework and a system for preventing cross-site request forgery (CSRF) attacks. The CSRF-protection system is based on a random nonce sent to the client in a cookie which must be sent by the client on future requests, and in forms a hidden value which must be submitted back with the form. The caching framework includes an option to cache responses to anonymous (i.e., unauthenticated) clients. When the first anonymous request to a given page was by a client which did not have a CSRF cookie, the cache framework will also cache the CSRF cookie, and serve the same nonce to other anonymous clients who do not have a CSRF cookie. This allows an attacker to obtain a valid CSRF cookie value and perform attacks which bypass the check for the cookie. To remedy this, the caching framework will no longer cache such responses. The heuristic for this will be: 1. If the incoming request did not submit any cookies, and 2. The response did send one or more cookies, and 3. The ``Vary: Cookie`` header is set on the response, then the response will not be cached. Issue: MySQL typecasting ======================== The MySQL database is known to "typecast" on certain queries; for example, when querying a table which contains string values, but using a query which filters based on an integer value, MySQL will first silently coerce the strings to integers, and return a result based on that. Django's model field classes are aware of their own types, and most such classes perform explicit conversion of query arguments to the correct database-level type before querying. However, three model field classes did not correctly convert their arguments: * ``FilePathField`` * ``GenericIPAddressField`` * ``IPAddressField`` These three fields have been updated to convert their arguments to the correct types before querying. Additionally, developers of custom model fields are now warned via documentation to ensure their custom field classes will perform appropriate type conversions, and users of the ``raw()`` and ``extra()`` query methods -- which allow the developer to supply raw SQL or SQL fragments -- will be advised to ensure they perform appropriate manual type conversions prior to executing queries. Affected versions ================= * Django master development branch * Django 1.7 (currently at beta status) * Django 1.6 * Django 1.5 * Django 1.4 Resolution ========== Included with this email are patches implementing the changes described above, for each affected version of Django. These patches will be applied to the Django development repository on Monday, April 21, 2014, and the following releases will be issued along with disclosure of the above issues: * Django 1.7 beta 2 * Django 1.6.3 * Django 1.5.6 * Django 1.4.11 As Django 1.7 is currently in a beta 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. [1] https://www.djangoproject.com/security/
Assignee: nobody → willkg
Curtis: I wrote up the bug and was already cc:d, so I know about it. I didn't assign it to myself in case Ricky wanted to take it.
I'll take it! And do it together with sumo.
Assignee: willkg → rrosario
Not sure if these ernest bits are right...
Whiteboard: u=dev c=general p=1 s=2014q2
Target Milestone: --- → 2014Q2
Fixed the sprint. Thank you, Ricky!
Whiteboard: u=dev c=general p=1 s=2014q2 → u=dev c=general p=1 s=input.2014q2
https://www.djangoproject.com/weblog/2014/apr/21/security/ The Django security release has been issued. Please update the Django to the appropriate security release.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Assignee: rrosario → willkg
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.