Security releases and advisory issued

Posted by Daniele Procida and Tim Graham on March 9, 2015

In accordance with our security release policy, the Django team is issuing multiple releases -- Django 1.7.6 and Django 1.8b2. These releases are now available on PyPI and our download page. These releases address a security issue in the Django admin. We encourage all users of Django to upgrade as soon as possible. The Django master branch has also been updated. If you are using a Django version older than 1.7, the security issue in the admin does not affect you, but there is an important advisory below regarding similar vulnerabilities that may exist in your own code.

Usually we prenotify certain key organizations when we make security releases, but unfortunately in this case a public disclosure of the vulnerability was made, forcing us to issue a release without the usual process.

Issue: XSS attack via properties in ModelAdmin.readonly_fields

The ModelAdmin.readonly_fields attribute in the Django admin allows displaying model fields and model attributes. While the former were correctly escaped, the latter were not. Thus untrusted content could be injected into the admin, presenting an exploitation vector for XSS attacks.

In this vulnerability, every model attribute used in readonly_fields that is not an actual model field (e.g. a @property) will fail to be escaped even if that attribute is not marked as safe. In this release, autoescaping is now correctly applied.

This issue has been assigned the identifier CVE-2015-2241.

Advisory: HTML escaping when calling template filters from Python code

The vulnerability described above was caused by the admin's use of the linebreaksbr function which doesn't escape its output by default when used outside of a template.

This same behavior is present in other functions from django.template.defaultfilters that output HTML:

  • join
  • linebreaksbr
  • linebreaks_filter
  • linenumbers
  • unordered_list
  • urlize
  • urlizetrunc

In versions older than 1.8b2, they use autoescape=None as a default argument. This means when calling these functions directly from Python code, the input would be marked safe, but is not actually escaped, creating an XSS attack vector.

We've remedied this issue in 1.8b2+ by changing the default value of this option to True. This ensures a safe behavior by default and helps prevent similar cases in the future. In addition, the documentation for writing custom template filters has been updated to recommend True as the default value.

The change of the default parameter in 1.8 may create a compatibility issue for some users, but we feel it's important to use safe defaults. If escaping is not desired for your calls of these functions, you can revert to the old behavior by passing autoescape=False.

Users of Django versions 1.0 to 1.7 should check their code for Python calls to these filters and ensure that any usage either explicitly sets autoescape=True or passes only trusted content.

This issue only affects these template filters when they are called directly from Python code and not when they are used in templates.

Affected versions

  • Django master development branch (currently at pre-alpha status)
  • Django 1.8 (currently at beta status)
  • Django 1.7

Resolution

Patches have been applied to Django's master development branch and to the 1.7 and 1.8 release branches. The patches may be obtained from the following changesets:

The following new releases have been issued:

Disclosing security vulnerabilities

While we are always thrilled to receive reports of bugs that we can fix, we implore members of our community not to report security issues publicly. Reporting them privately allows us to prepare patches that can be released along with the public disclosure, and to prenotify key organizations. Public reports on the other hand expose users to greater risk and places undue strain on the team responsible for coming up with a solution.

For information about how to disclose a vulnerability and how those are handled by the Django team, please refer to our security release policy.

Back to Top