841772 - Update to Django 1.4.5

Status: RESOLVED FIXED

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

Description

[James Socol [:jsocol, :james]]

Attachment: zip file of patches

+++ This bug was initially created as a clone of Bug #841767 +++

We got a security pre-notification from the Django project and a tip that Python may also release a new version addressing a vulnerability in a stdlib XML package.

Both releases are expected on Tuesday, 19 February.

There are 4 issues addressed in these releases (1.3.6, 1.4.4, and 1.5rc2) and upgrades need to be performed ASAP. The full notification is below.

===============================================

You're receiving this message because you are on the security
pre-notification list for the Django web framework; information about
this list can be found in our security policy[1].

In accordance with that policy, on Tuesday, February 19, 2013, the
Django project will be issuing a set of releases to remedy several
security issues reported to us. This message contains a description of
the issues, a description of the changes which will be made to Django,
and the patches which will be applied to Django.


Issue: Host header poisoning
============================

Several previous Django security releases have attempted to address
persistent issues with the HTTP ``Host`` header. Django contains code
-- and some functionality shipped with Django itself makes use of that
code -- for constructing a fully-qualified URL based on the incoming
HTTP request. Depending on configuration, this makes use of the
``Host`` header, and so an attacker who can cause a Django application
to respond to arbitrary ``Host`` headers can cause Django to generate,
and display to end users, URLs on arbitrary domains.

Previous iterations of this issue (see CVE-2011-4139 and
CVE-2012-4520) have focused on tightening Django's parsing of ``Host``
headers, to eliminate various means by which attackers -- using
techniques such as username/password pairs in their submitted ``Host``
header -- could exploit this.

Ultimately, however, Django alone cannot ensure that an attacker is
unable to submit, and cause Django to accept, arbitrary ``Host``
headers. Properly securing this in a deployed Django instance
additionally requires configuration of the web server, and both the
configuration and the achievable level of security vary with the
server being used.

In light of this, the ``get_host()`` method of
``django.http.HttpRequest`` will now validate the ``Host`` header
against a new setting, ``ALLOWED_HOSTS``. This setting is a
list of strings (by default, an empty list) corresponding to
acceptable values for the header, with some support for wildcards.

Code which does not use ``get_host()``, or Django configurations which
can determine the current hostname without recourse to HTTP headers
(i.e., when Django's sites framework is enabled) will not be affected
by this change.


Issue: XML entity expansion attacks
===================================

Django's serialization framework includes support for serializing to,
and deserializing from, XML. Django's XML deserialization is
vulnerable to entity-expansion attacks.

To remedy this, Django's XML deserializer will now skip processing of
external entities. As this vulnerability is also present in the
underlying XML-handling modules of the Python standard library, a
security release of Python addressing the issue at that level is
expected simultaneous with Django's release.


Issue: Data leakage via admin history log
=========================================

Django's bundled administrative interface keeps a log of actions
taken, preserving the history of any object which is exposed through
the admin interface. This history view does not perform any permission
checks beyond confirming that the user has access to the
administrative interface; as such, any user with admin access can view
the history of any object accessible in the admin interface, and see
summaries of each change made to an object.

To remedy this, the admin history view for an object will now perform
the same permission checks as other admin views for the same object.


Issue: Formset denial-of-service when max_num not set
=====================================================

Django's form library includes tools for generating formsets --
multiple instances of a single form, to be submitted simultaneously
(e.g., for mass editing/updating of similar objects). Formsets allow a
parameter, ``max_num``, specifying the maximum number of individual
forms which may be included. The number of forms being submitted is
included in a hidden field in the formset; when ``max_num`` is
specified, this value is validated against ``max_num``.

When ``max_num`` is not specified, however, Django accepts the
submitted hidden value, and attempts to instantiate that many form
objects. Sufficiently large values will result in extreme memory
consumption; values exceeding ``sys.maxint`` will, in this case,
result in an HTTP 500 response (due to an uncaught ``OverflowError``
from the over-large value). In either case, the result is an effective
denial-of-service attack.

To resolve this, Django will now supply a (suitably large) default
value for ``max_num``. Application developers can still manually
specify ``max_num`` to suit the needs of their applications, but
absent this the default value -- 1000 -- will ensure that attackers
cannot cause overflow errors or excessive memory consumption.


Affected versions
=================

The issues described above affect the following versions of Django:

* Django master development branch

* Django 1.5 release branch (soon to become Django 1.5)

* Django 1.4 release branch

* Django 1.3 release branch


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 Tuesday,
February 19, 2013, and the following releases will be issued along
with disclosure of the reasons for these changes:

* Django 1.5 release candidate  2

* Django 1.4.4

* Django 1.3.6

As Django's master development branch is currently in a pre-alpha
state, and the 1.5 branch is in a pre-release state, users are
strongly advised not to be running production deployments from them;
the disclosure announcement will nonetheless include a reminder of
this and encourage any such users to update their checkouts
immediately.

Comment 1

[James Socol [:jsocol, :james]]

This release is now public. This is a critical update. Please upgrade and deploy ASAP.

https://www.djangoproject.com/weblog/2013/feb/19/security/

Comment 2

[James Socol [:jsocol, :james]]

This is ongoing, assigning to James.

Comment 4

[John Karahalis [:openjck]]

Hey :ubernostrum. In the meeting today, we talked about offering help with the front-end parts of this if you need it. Just let us know.

Comment 5

[Luke Crouch [:groovecoder]]

Merged https://github.com/mozilla/kuma/pull/962

Comment 6

[James Socol [:jsocol, :james]]

/me throws a small dance party.

Comment 7

[Luke Crouch [:groovecoder]]

vids or it didn't happen.

Comment 8

[Raymond Forbes[:rforbes]]

when will this be in production?

Comment 9

[Les Orchard [:lorchard]]

It's in production right now, and we're shaking out the last few bugs.

Comment 10

[Raymond Forbes[:rforbes]]

i see it now, thanks!

Comment 11

[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.