996928 - django 1.4.11/1.5.6/1.6.3 security update (MDN)

Status: RESOLVED FIXED

(developer.mozilla.org :: Security, defect, P1)

Description

[Will Kahn-Greene [:willkg] ET needinfo? me]

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/

Comment 1

[Luke Crouch [:groovecoder]]

:ubernostrum can you take this?

Comment 2

[James Bennett [:ubernostrum]]

I will be home from PyCon by the time these land, so yes.

Comment 3

[Will Kahn-Greene [:willkg] ET needinfo? me]

James: You're the best!

One thing I meant to describe in the bug is how I heard about the issue. I was walking casually through a parking garage in Montreal in the dead of night returning from an evening of drunken debauchery aka fiddling with Emacs configurations. A man approached me. I couldn't really see him because he was completely enveloped in shadow. Strangely, the shadow seemed to follow him wherever he went. In a raspy voice he said, "Will. Do you still write up those security bugs?" I, unsure of who I was speaking to, said, "Uh. Right. Sure. Yes, I do." Then the raspy voice said, "You will write more bugs in your near future. Prepare for the hour of darkness grows nigh." Then I heard a weird sound at my feet. I looked down. As soon as I looked up again preparing to ask more questions like "what does nigh mean?", the shadowy figure had melted into the darkness once more and I discovered that I was standing in an empty parking garage in Montreal once more. Also, I had a sudden hankering for poutine.

It was all very odd.

Comment 4

[James Bennett [:ubernostrum]]

Quick audit of kuma shows no unsafe uses of reverse().

I'll move on to checking for potential typecasting issues.

Comment 5

[Will Kahn-Greene [:willkg] ET needinfo? me]

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.

Comment 6

[James Bennett [:ubernostrum]]

I'm going to call a hold on this temporarily, for two reasons:

1. The bugs aren't terribly urgent, and after auditing I'm 99% sure we're not exploitable anyway, and

2. It's likely there'll be a followup bugfix 1.4.12 soon due to https://code.djangoproject.com/ticket/22486

Comment 7

[Jannis Leidel [:jezdez]]

IIRC we've upgraded to 1.4.13 right?

Comment 8

[James Bennett [:ubernostrum]]

We upgraded a while back; we've also now finished the upgrade for bug 1053849.

Comment 9

[Will Kahn-Greene [:willkg] ET needinfo? me]

For bugs that are resolved, we remove the security flag. These haven't had their flag removed, so I'm removing it now.