Weblog

September archive

DjangoCon US 2013 wrapup

September 20, 2013

DjangoCon US 2013 has finished for another year -- which means the hard work to organize DjangoCon US 2014 has just begun!

If you were an attendee at DjangoCon US this year, you should have received an invitation to participate in a survey on your conference experience. This feedback is incredibly valuable as it helps to shape our plans for next year. If you were able to make it to Chicago, we strongly encourage you to fill out this survey.

However, we're not just interested in hearing the opinion of attendees. If you didn't attend DjangoCon US, we'd like to know why! If there's something we could have done to convince you to attend, we want to know about it so that we can fix it for next year. Get in touch and let us know what we should have done better.

Even more important than ideas and feedback are volunteers. Any plans we make are only as good as the people who turn those plans into reality, and we need volunteers to make this happen. Much of the activity you see around DjangoCon US is organized by volunteers, including:

  • The conference website
  • Organizing the Call for Papers
  • Reviewing and selecting the talks for the conference program
  • Organizing keynote speakers
  • Organizing sponsors
  • Session chairs during the conference
  • Organizing the post-conference sprint
  • ... and much more.

If you're interested in helping for DjangoCon US 2014, you can join the DjangoCon Organizers mailing list. This list is free for anyone to join. It doesn't matter whether you're a veteran DjangoCon attendee, or you're attending for the first time -- we'll accept volunteer help from anyone.

Next year, DjangoCon US will be returning to Portland, Oregon, so we're obviously interested in anyone who is a Portland native who can help with coordination on the ground. However, you can help even if you're not a Portland local. Much of volunteer activity prior to the conference itself is conducted online.

So - let us know what we can do better, and help us make those plans a reality. We hope we'll see even more of you in Portland in September next year!

Announcing the Malcolm Tredinnick Memorial Prize

September 16, 2013

Malcolm Tredinnick joined the Django project as a core developer in early 2006. He was deeply involved in many part of Django - most notably, the ORM, but many other internals bear his fingerprints. Django’s support for unicode, and autoescaping in templates can both be almost entirely attributed to Malcolm.

But his contributions weren't just code. He was also a prolific communicator. He logged thousands of messages in django-users, helping people learn Django, sharing his expertise freely and openly. He also logged thousands of messages in django-developers, helping shape the framework we all use today.

And if that wasn't enough, Django wasn’t the only community that Malcolm was part of. Malcolm was also a contributor to GNOME, and served on the GNOME Foundation board. He was also an active participant in the Australian chess community, mentoring young players.

On March 17 this year, Malcolm suffered a brain aneurysm and passed away. Malcolm's death was a shock to everyone who knew him. To say that we miss him is an understatement.

With Malcolm’s memory in mind, the Django Software Foundation is proud to announce that with this blessing of his family, we will be establishing an award in Malcolm’s name.

The award will be a monetary prize, awarded annually, to the person who best exemplifies the spirit of Malcolm’s work - someone who welcomes, supports and nurtures newcomers; freely gives feedback and assistance to others, and helps to grow the community. The hope is that the recipient of the award will use the award stipend as a contribution to travel to a community event -- a DjangoCon, a PyCon, a sprint -- and continue in Malcolm’s footsteps.

At this time, the DSF is making a twofold call.

Firstly, we’re making a call for donations to the fund that will back the award. We need people in the community to donate money so that the DSF is in a position to grant this award on an annual basis. If you wish to contribute financially to the prize fund, you can donate via PayPal, or get in touch if you'd like a different option (like a direct bank transfer).

Secondly, we’re calling for nominees for the inaugural recipient of the award. The DSF board will accept nominations from anyone in the community. The board will narrow that list down to a short list, and put that short list to the DSF membership for a final vote. If you would like to nominate someone as the inaugural winner of the award, get in touch.

The DSF board aims to make an announcement of the first recipient of this award in early October. We hope you'll join us in lighting a candle in Malcolm’s memory.

UPDATE: 10:45 PM - provided link to PayPal donation page.

Security releases issued

September 15, 2013

Today the Django team is issuing multiple releases -- Django 1.4.8, Django 1.5.4, and Django 1.6 beta 4 -- to remedy a security issue which was disclosed publicly by a third party earlier today. These releases are now available on PyPI and our download page.

These releases address a denial-of-service attack against Django's authentication framework. All users of Django are encouraged to upgrade immediately.

Release outside of normal security process

Normally, our security process involves a one-week lead time for third parties on our security prenotification list. That process, however, relies on responsible disclosure practices which maintain confidentiality of a security issue until a coordinated public release date. To facilitate that, we ask that potential security issues always be reported via email to security@djangoproject.com, rather than through public channels such as Django's ticket tracker or the django-developers mailing list.

This issue, unfortunately, could not be handled by our normal process, as it was first reported publicly on the django-developers mailing list. It has since been confirmed by the Django core team, and due to the already-public nature of the issue and the potential to impact live deployments of Django, we are instead issuing security releases immediately.

Issue: denial-of-service via large passwords

Django's authentication framework -- django.contrib.auth -- includes a default User model and backend which authenticates via username and password. The raw password is not stored in the database; instead, a hashed version of the password is stored, and the hash is computed each time a user attempts to log in. The hasher to use is configurable, via the PASSWORD_HASHERS setting.

The default password hasher in Django is PBKDF2, which has the virtue of allowing the complexity of computing the hash to be effectively arbitrarily high, by repeated "rounds" of application before producing the final result. This increases the difficulty of attacks which use brute-force methods to compute the hashes of many possible plaintext values, in hopes of discovering which plaintext password corresponds to a given hashed value.

Unfortunately, this complexity can also be used as an attack vector. Django does not impose any maximum on the length of the plaintext password, meaning that an attacker can simply submit arbitrarily large -- and guaranteed-to-fail -- passwords, forcing a server running Django to perform the resulting expensive hash computation in an attempt to check the password. A password one megabyte in size, for example, will require roughly one minute of computation to check when using the PBKDF2 hasher.

This allows for denial-of-service attacks through repeated submission of large passwords, tying up server resources in the expensive computation of the corresponding hashes.

Although this is most effective against algorithms which are designed to be relatively "slow" to compute, such as PBKDF2 (which, again, is the default hasher in Django's authentication framework), it also is effective against other hashers, as the time to compute the hash generally grows with the size of the password.

To remedy this, Django's authentication framework will now automatically fail authentication for any password exceeding 4096 bytes.

Affected versions

  • Django master development branch
  • Django 1.6 (currently at beta status)
  • Django 1.5
  • Django 1.4

At the time of this writing, efforts are being made to obtain a CVE for this issue. This post will be updated with the CVE once it has been obtained.

Update: this issue was assigned CVE-2013-1443.

Resolution

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

The following new releases have been issued:

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. If you think you may have found a security issue but aren't sure, we urge you to err on the side of caution, and report via email rather than public channels. Please see our security policies for further information.

Django Software Foundation adopts trademark policy

September 12, 2013

The Django Software Foundation is the custodian of two major pieces of intellectual property. The first is the copyright to the Django codebase. The DSF manages copyrights by gathering contributor license agreements from everyone who contributes code to the Django project. This, in turn, allows the DSF to offer Django for distribution under the terms of the BSD license.

The second piece of intellectual property is the Django trademark - that is:

  • the name “Django” when used to describe software;
  • The logo comprised of the name Django rendered in color #092E20; in the font DTL Prokyon.

The name Django is a registered trademark in the US (USPTO serial number 78680396). The trademark isn’t formally registered in other jurisdictions, but as a result of continued usage, we still have common law rights to the name in most jurisdictions.

Earlier this year, the Python community got a wake up call in the form of the conflict over python.co.uk. That was a trademark dispute - it was about the use of the name Python to identify computer software in Europe. While that challenge was defeated, it made it clear that open source communities need to be more active around protection of their trademarks. As a community, we need to protect our trademark, and we need to be seen to be protecting it, or we’ll lose the ability to protect against attacks similar to those that endured by Python.

For this reason, the DSF has adopted a trademark licensing agreement to govern community use of the Django trademark.

This agreement isn't something you need to sign. It’s an agreement in the same way that the BSD license is Django’s copyright agreement - by using Django’s code, you agree to adhere to the terms of the BSD license; if you use Django’s Trademark, you’re agreeing to adhere to the terms of our trademark licensing agreement.

The full text of the agreement can be found at http://djangoproject.com/trademarks/, along with an extensive FAQ describing why we've taken this step, and common ways the license would be used in practice. By publishing this license, the DSF is making it clear what we consider to be acceptable use of the Django trademark. The hope is that this will give the community the liberty to pursue interesting ideas, while the DSF will retain the ability to protect the trademark against those who would exploit it.

It’s important to note that the licensing agreement is the start of the discussion, not the end. The terms here are generic terms that the DSF is comfortable offering to everyone. If your usage doesn’t fit these terms, or you have specific concerns, the DSF is in a position to offer you specific terms that meet your needs. If you think you fall into this category, or if you have any other questions or concerns about this trademark licensing policy, please get in touch.

Security releases issued

September 10, 2013

Today the Django team is issuing multiple releases -- Django 1.4.7, Django 1.5.3, and Django 1.6 beta 3 -- as part of our security process. These releases are now available on PyPI and our download page

These releases address a directory-traversal vulnerability in one of Django's built-in template tags. While this issue requires some fairly specific factors to be exploitable, we encourage all users of Django to upgrade promptly.

For more details, read on.

Issue: directory traversal with ssi template tag

Django's template language includes two methods of including and rendering one template inside another:

  1. The {% include %} tag takes a template name, and uses Django's template loading mechanism (which is restricted to the directories specified in the TEMPLATE_DIRS setting, as with any other normal template load in Django).
  2. The {% ssi %} tag, which takes a file path and includes that file's contents (optionally parsing and rendering it as a template).

Since the ssi tag is not restricted to TEMPLATE_DIRS, it represents a security risk; the setting ALLOWED_INCLUDE_ROOTS thus is required, and specifies filesystem locations from which ssi may read files.

A report has been submitted to and confirmed by the Django core team, showing that the handling of the ALLOWED_INCLUDE_ROOTS setting is vulnerable to a directory-traversal attack, by specifying a file path which begins as the absolute path of a directory in ALLOWED_INCLUDE_ROOTS, and then uses relative paths to break free. So, for example, if /var/includes is in ALLOWED_INCLUDE_ROOTS, the following would be accepted:

{% ssi '/var/includes/../../etc/passwd' %}

Which would include the contents of /etc/passwd in the template's output.

Note that performing this attack does require some specific circumstances:

  • The site to be attacked must have one or more templates making use of the ssi tag, and must allow some form of unsanitized user input to be used as an argument to the ssi tag, or
  • The attacker must be in a position to alter templates on the site.

To remedy this, the ssi tag will now use Python's os.path.abspath to determine the absolute path of the file, and whether it is actually located within a directory permitted by ALLOWED_INCLUDE_ROOTS.

Thanks to Rainer Koirikivi for reporting this issue to us.

Affected versions

  • Django master development branch
  • Django 1.6 (currently at beta status)
  • Django 1.5
  • Django 1.4

For all affected versions of Django, use CVE-2013-4315 to refer to this issue.

Resolution

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

The following new releases have been issued:

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.