1145128 - Django 1.4.20/1.6.11/1.7.7 security update (MDN)

Status: RESOLVED FIXED

(developer.mozilla.org :: Security, defect)

Description

[Will Kahn-Greene [:willkg] ET needinfo? me]

On Wednesday, March 18th, 2015, the Django project issued a set  of releases to remedy security issues reported. This bug contains descriptions of the issues.

Please read the entirety of this bug. Then either:

1. apply the update and mark this bug as FIXED, or

2. verify this doesn't apply to your project and close this bug with a WONTFIX plus an explanation of why these don't apply to your project


From the blog entry at https://www.djangoproject.com/weblog/2015/mar/18/security-releases/

"""
In accordance with our security release policy, the Django team is issuing multiple releases -- Django 1.4.20, 1.6.11, 1.7.7 and 1.8c1. These releases are now available on PyPI and our download page. These releases address several security issues detailed below. We encourage all users of Django to upgrade as soon as possible. The Django master branch has also been updated.

Django 1.8 is now at release candidate stage. This marks the string freeze and the call for translators to submit translations. Provided no major bugs are discovered that can't be solved in the next two weeks, 1.8 final will be issued on or around April 1. Any delays will be communicated on the django-developers mailing list thread.


Denial-of-service possibility with strip_tags()
===============================================

Last year django.utils.html.strip_tags was changed to work iteratively. The problem is that the size of the input it's processing can increase on each iteration which results in an infinite loop in strip_tags(). This issue only affects versions of Python that haven't received a bugfix in HTMLParser; namely Python < 2.7.7 and 3.3.5. Some operating system vendors have also backported the fix for the Python bug into their packages of earlier versions.

To remedy this issue, strip_tags() will now return the original input if it detects the length of the string it's processing increases. Remember that absolutely NO guarantee is provided about the results of strip_tags() being HTML safe. So NEVER mark safe the result of a strip_tags() call without escaping it first, for example with django.utils.html.escape.

Thanks Andrey Babak for reporting the issue.

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


Mitigated possible XSS attack via user-supplied redirect URLs
=============================================================

Django relies on user input in some cases (e.g. django.contrib.auth.views.login and i18n) to redirect the user to an "on success" URL. The security checks for these redirects (namely django.utils.http.is_safe_url()) accepted URLs with leading control characters and so considered URLs like \x08javascript:... safe. This issue doesn't affect Django currently, since we only put this URL into the Location response header and browsers seem to ignore JavaScript there. Browsers we tested also treat URLs prefixed with control characters such as %08//example.com as relative paths so redirection to an unsafe target isn't a problem either.

However, if a developer relies on is_safe_url() to provide safe redirect targets and puts such a URL into a link, they could suffer from an XSS attack as some browsers such as Google Chrome ignore control characters at the start of a URL in an anchor href.

Thanks Daniel Chatfield for reporting the issue.

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


Affected versions
=================

    Django master development branch
    Django 1.8 (currently at release candidate status)
    Django 1.7
    Django 1.6
    Django 1.4 (is_safe_url() issue only)

Per our supported versions policy, Django 1.5 is no longer receiving security updates.
"""

Comment 1

[Jannis Leidel [:jezdez]]

We're running 1.7.8 now and Python 2.7.9. We also don't mark the result of the one instance of strip_tags as safe (https://github.com/mozilla/kuma/blob/8f3241ddf5563d235f319fda51701825ab977f1e/kuma/landing/templates/landing/newsfeed.html#L6).

We don't use is_safe_url in the way mentioned in our code and django-allauth seems to only use it in Location headers as well. The place where we *do* use allauth's utility to get the next URL (https://github.com/mozilla/kuma/blob/8f3241ddf5563d235f319fda51701825ab977f1e/kuma/users/providers/github/views.py#L32-L38) we pass the generated "safe" URL as a hidden form input value as as the "next" parameter (https://github.com/mozilla/kuma/blob/8f3241ddf5563d235f319fda51701825ab977f1e/kuma/users/templates/socialaccount/signup.html#L36-L50). We populate that value via JavaScript (https://github.com/mozilla/kuma/blob/51cbf4c45a1791b954c675d6e7b9dfb5cb420750/media/js/auth.js#L15).

All in all, I would consider this to be very hard or even impossible to abuse. Feel free to reopen if you don't follow my arguments.

Comment 2

[Will Kahn-Greene [:willkg] ET needinfo? me]

For bugs that are resolved, we remove the security flag. These haven't had their flag removed, so I'm removing it now.