Weblog

December archive

Django 1.3 beta 1 released

December 22, 2010

As part of the Django 1.3 release process, tonight we've released Django 1.3 beta 1, a preview/testing package that gives a little taste of some of the new features coming in Django 1.3. As with all alpha and beta packages, this is not for production use, but if you'd like to try out some of the new goodies coming in 1.3, or if you'd like to pitch in and help us fix bugs before the final 1.3 release (due in January), feel free to grab a copy and give it a spin.

Also, note that this beta release contains the patches mentioned in the security announcement earlier today. If you're using Django 1.3 alpha 1, you're urged to upgrade to beta 1 or apply the trunk patches immediately.

You can get a copy of the 1.3 beta package from our downloads page, and we recommend you read the release notes. Also, for the security conscious, signed MD5 and SHA1 checksums of the 1.3 beta package are available.

Security releases issued

December 22, 2010

Today the Django team is issuing multiple releases -- Django 1.2.4, Django 1.1.3 and Django 1.3 beta 1 -- to remedy two security issues reported to us. All users of affected versions of Django are urged to upgrade immediately.

Information leakage in Django administrative interface

The Django administrative interface, django.contrib.admin, supports filtering of displayed lists of objects by fields on the corresponding models, including across database-level relationships. This is implemented by passing lookup arguments in the querystring portion of the URL, and options on the ModelAdmin class allow developers to specify particular fields or relationships which will generate automatic links for filtering.

One historically-undocumented and -unofficially-supported feature has been the ability for a user with sufficient knowledge of a model's structure and the format of these lookup arguments to invent useful new filters on the fly by manipulating the querystring.

As reported to us by Adam Baldwin, however, this can be abused to gain access to information outside of an admin user's permissions; for example, an attacker with access to the admin and sufficient knowledge of model structure and relations could construct querystrings which -- with repeated use of regular-expression lookups supported by the Django database API -- expose sensitive information such as users' password hashes.

To remedy this, django.contrib.admin will now validate that querystring lookup arguments either specify only fields on the model being viewed, or cross relations which have been explicitly whitelisted by the application developer using the pre-existing mechanism mentioned above. This is backwards-incompatible for any users relying on the prior ability to insert arbitrary lookups, but as this "feature" was never documented or supported, we do not consider it to be an issue for our API-stability policy. The release notes for Django 1.3 beta 1 -- which will include this change -- will, however, note this difference from previous Django releases.

Denial-of-service attack in password-reset mechanism

Django's bundled authentication framework, django.contrib.auth, offers views which allow users to reset a forgotten password. The reset mechanism involves generating a one-time token composed from the user's ID, the timestamp of the reset request converted to a base36 integer, and a hash derived from the user's current password hash (which will change once the reset is complete, thus invalidating the token).

The code which verifies this token, however, does not validate the length of the supplied base36 timestamp before attempting to convert it. An attacker with sufficient knowledge of a site's URL configuration and the manner in which the reset token is constructed can, then, craft a request containing an arbitrarily-large (up to the web server's maximum supported URL length) base36 integer, which Django will blindly attempt to convert back into a timestamp.

As reported to us by Paul McMillan, the time required to attempt this conversion on ever-larger numbers will consume significant server resources, and many such simultaneous requests will result in an effective denial-of-service attack. Further investigation revealed that the password-reset code blindly converts base36 in multiple places.

To remedy this, the base36_to_int() function in django.utils.http will now validate the length of its input; on input longer than 13 digits (sufficient to base36-encode any 64-bit integer), it will now raise ValueError. Additionally, the default URL patterns for django.contrib.auth will now enforce a maximum length on the relevant parameters.

Affected versions

Both of the issues described above are present in the following currently-supported Django versions:

  • Django development trunk
  • Django 1.2
  • Django 1.1

Resolution

Patches have been applied to Django trunk, and to the 1.2 and 1.1 release branches, which resolve both issues described above. The patches may be obtained directly from the appropriate changesets:

The following new releases have been issued:

Django 1.3 beta 1, which will contain the patch from Django trunk, will also be issued later today.

General notes regarding security

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

Due to the impending Christmas and New Year's holiday, our normal process of notifying distributors of Django one week in advance of security-releated release was shortened somewhat to allow these releases to be issued before most Django users take their holiday vacations.

If you are or represent a third-party distributor of Django and did not receive a notification email from the Django release manager, please contact james@b-list.org.

Django 1.3 release schedule -- Update

December 13, 2010

Once again, astute observers will have noted a missed deadline: November 29 has come and gone, but Django 1.3 beta 1 hasn't been released.

In this case, the delay has been caused by a desire to deliver on everything that has been discussed over the last few months. The release of Beta 1 marks the full feature freeze for Django 1.3, and there are lots of little features that have been discussed at length, and are very close to completion, but haven't been committed to trunk. Rather than defer these features to the 1.4, we've opted to push the release schedule by a couple of weeks to let the last few commits happen.

At this point, the outstanding issues are:

  • #7817: Modification of the {% with %} to support multiple assignment
  • #9456: Modification of the {% include %} tag to support subtemplate assignment
  • #11675: Addition of a pylibmc cache backend
  • #14844: dealing with pluralization rules in {% blocktrans %}
  • Some administrative i18n issues, aimed at allowing translators to use Transifex to keep translations up to date

In order to accommodate these last features, we've decided to push the Beta 1 release until December 21.

To ensure that we have enough time for fixing bugs once the beta has been released, we're also going to push the final release date by 2 weeks. This means the 1.3 release candidate should be released on January 24, followed by a final 1.3 release on January 31.

Once the beta has been released, we will be focussing on bug fixes. We will be using the Ready For Checkin list as the working list, so if you have a bug you want to see fixed, make sure it has been reviewed and is correctly tagged for as being ready for checkin. We also need assistance triaging the list of unreviewed tickets.

If you're not sure what you need to do in order to get your ticket ready for checkin, read the contribution guide; we also have a work-in-progress HowTo guide that may help clarify what is needed. If you're still not sure, try asking on the #django-dev IRC channel for a push in the right direction.