bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

Upcoming Django and Python security releases (1.3.6/1.4.4/1.5rc2)

RESOLVED FIXED in 2013Q1

Status

support.mozilla.org
General
P1
normal
RESOLVED FIXED
6 years ago
2 years ago

People

(Reporter: jsocol, Assigned: willkg)

Tracking

unspecified
2013Q1

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: u=user c=site p=1 s=2013.4)

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
Created attachment 714391 [details]
zip file of patches

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.
(Reporter)

Updated

6 years ago
Blocks: 841768
(Reporter)

Updated

6 years ago
No longer blocks: 841768
(Reporter)

Comment 1

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

https://www.djangoproject.com/weblog/2013/feb/19/security/
Grabbing this one. Should be straight-forward.
Assignee: nobody → willkg
Pushed to -stage and -prod just now.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Adding metadata.
Priority: -- → P1
Whiteboard: u=user c=site p=1 s=2013.4
Target Milestone: --- → 2013Q1
We have one instance of get_host() in kitsune/apps/ and kitsune/vendor/ (discluding django which of course has get_host() in a few places).

I think this is something we need to set in the settings_local for each individual environment. e.g. -dev gets ALLOWED_HOSTS = ['support-dev.allizom.org']

Does that sound right?
(Reporter)

Comment 7

6 years ago
Sounds right to me, yes.
All set on kitsune!
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.