Weblog

February archive

Django 1.5 released

February 26, 2013

It's here!

After quite a lot of work, today we're proud to announce the release of Django 1.5. As always, the release notes cover all the good stuff in detail, but since this is a pretty big release let's take a look at some of the highlights:

  • Django 1.5 introduces support for a configurable User model. The basic Django User model is still around, of course, but now there's first-class support for specifying your own model and having Django's auth system make use of it.

  • Django 1.5 is the first Django release with support for Python 3 (specifically, Python 3.2 and newer). Python 3 support is still considered experimental -- largely because it hasn't received as much real-world testing as we'd like -- but a Python 3 porting guide is available if you'd like to give it a try, and we will be considering Python 3 compatibility bugs to be blockers for future releases.

    Of course, if you're still comfortable with Python 2, Django continues to offer support for that just as we always have -- though note that the minimum version for Django 1.5 is Python 2.6.5, and Python 2.7.3 or newer is strongly recommended.

  • Django's documentation has also gotten some pretty significant work; the main documentation page has had a bit of a facelift to make things easier to find, the existing tutorial got some refurbishing, and several new tutorials -- including some more advanced topics, like writing an app you can reuse in multiple projects -- have been added. And the documentation for class-based views has been significantly expanded, which should make this feature a lot easier to understand and take advantage of.

And that's just the tip of the iceberg; Django 1.5 has a whole lot more to offer, all of which is covered in the release notes.

Meanwhile, Django 1.5 itself is available from our downloads page (see also: checksums for package verification), or from your favorite Python package manager.

Finally, as always we want to point out that we couldn't do this without the help of huge numbers of people from around the world; the Django community grows every day, and the number of people who've contributed to Django grows with every release. You're both the reason we do this, and the reason why we can do this, so give yourselves all a big pat on the back.

Updated releases issued

February 20, 2013

Today the Django team is issuing two releases -- Django 1.3.7 and 1.4.5 -- to correct a packaging problem with yesterday's 1.3.6 and 1.4.4 releases.

Both the 1.3.6 and 1.4.4 releases of Django contained stray .pyc files that caused "bad magic number" errors when running with some versions of Python. The 1.3.7 and 1.4.5 releases correct this, and also fix a bad documentation link in the project template settings.py file generated by manage.py startproject.

The following new releases have been issued:

Security releases issued

February 19, 2013

Today the Django team is issuing multiple releases -- Django 1.3.6, Django 1.4.4, and Django 1.5 release candidate 2 -- as part of our security process.

These releases remedy multiple issues reported to us, and involve one important end-user-visible change, so please read these notes carefully.

Summary

These security releases fix four issues: one potential phishing vector, one denial-of-service vector, an information leakage issue, and a range of XML vulnerabilities.

Here's a brief summary of each issue and its resolution:

  • Issue: Host header poisoning: an attacker could cause Django to generate and display URLs that link to arbitrary domains. This could be used as part of a phishing attack. These releases fix this problem by introducing a new setting, ALLOWED_HOSTS, which specifies a whitelist of domains your site is known to respond to.

    Important: by default Django 1.3.6 and 1.4.4 set ALLOWED_HOSTS to allow all hosts. This means that to actually fix the security vulnerability you should define this setting yourself immediately after upgrading.

  • Issue: Formset denial-of-service: an attacker can abuse Django's tracking of the number of forms in a formset to cause a denial-of-service attack. This has been fixed by adding a default maximum number of forms of 1,000. You can still manually specify a bigger max_num, if you wish, but 1,000 should be enough for anyone.

  • Issue: XML attacks: Django's serialization framework was vulnerable to attacks via XML entity expansion and external references; this is now fixed. However, if you're parsing arbitrary XML in other parts of your application, we recommend you look into the defusedxml Python packages which remedy this anywhere you parse XML, not just via Django's serialization framework.

  • Issue: Data leakage via admin history log: Django's admin interface could expose supposedly-hidden information via its history log. This has been fixed.

For more details, read on.

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.

Since this is hardening/tightening of a previous issue, it does not have a new CVE number.

Issue: XML attacks

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

To remedy this, Django's XML deserializer no longer allows DTDs, performs entity expansion, or fetches external entities/DTDs. Note that this only protects Django's XML serialization framework; if your application parses XML, we recommend you look into the defusedxml Python packages which remedy this for Python itself.

Because this issue also affects Python's XML libraries, it is covered by Python's CVE-2013-1664 and CVE-2013-1665.

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.

This issue is CVE-2013-0305.

Issue: Formset denial-of-service

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 displayed. A hidden input in the formset then specifies the number of forms being submitted.

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 the former case, the result is an effective denial-of-service attack. In the latter, an attacker can cause arbitrary server errors.

To resolve this, Django will now supply a (suitably large) default value for the maximum number of forms, which will be used when max_num is not supplied. 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.

This issue is CVE-2013-0306.

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

Patches have been applied to Django's master development branch, and to the 1.5, 1.4 and 1.3 release branches, which resolve the issues described above. The patches may be obtained directly from the following changesets.

On the development master branch:

On the Django 1.5 release branch:

On the Django 1.4 release branch:

On the Django 1.3 release branch:

The following new releases have been issued:

Credits

Followup on the Host header issue again came from James Kettle. The XML vulnerability was reported to us by Michael Koziarski of Rails. The essentials of the patch came from Christian Heimes. The admin information leakage issue was reported by Orange Tsai. The formset validation issue was reported by Mozilla.

General notes regarding security reporting

As always, we ask that potential security issues be reported via private email to security@djangoproject.com, and not via Django's Trac instance or the django-developers list. Please see our security policies for further information.

Django Sprint in Kansas City

February 18, 2013

PythonKC is excited to announce that they'll be hosting a Kansas City contingant of the worldwide Django sprint on February 23-24. If you're in the Kansas City area and want to get involved in Django, sign up to join us!

Basically, a Django sprint is an excuse for people to focus their undivided attention, for a set time frame, on improving Django. It's a focused, scheduled effort to test, fix bugs, add new features and improve documentation.

This weekend we'll have sprints around the world -- Japan, San Francisco, Utrecht, Kraków, and Córdoba, and now Kansas City. If you're not able to make it in person, you can still participate by joining us online. Anybody, anywhere around the world, can participate and contribute. Most contributors will be at their own homes/schools/workplaces, but a number of people will gather together in person for camaraderie, improved communication and the other benefits of face-to-face interaction.

If you've never contributed to Django before, a sprint is the perfect chance for you to chip in.

We hope to see you there!

DSF requires Code of Conduct for support

February 12, 2013

At the January 9, 2013, the DSF will only sponsor events with a published Code of Conduct. Please see Code of Conduct for details.

We hope that this change will underscore our continued commitment to a diverse and healthy community. Please send feedback regarding this policy to the DSF board.