1252503 - Update to Django 1.8.10

Status: RESOLVED FIXED

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

Description

[John Whitlock [:jwhitlock]]

What problem would this feature solve?
======================================
The Django project issued 1.8.10 on March 1st, 2016, fixing two issues:

https://www.djangoproject.com/weblog/2016/mar/01/security-releases/



Who has this problem?
=====================
All visitors to MDN

How do you know that the users identified above have this problem?
==================================================================
We're not aware of active exploits of these issues, but now that the security release is public, the likelihood of attacks using these methods has increased.

How are the users identified above solving this problem now?
============================================================
MDN staff is quickly applying updates

Do you have any suggestions for solving the problem? Please explain in detail.
==============================================================================
Apply the 1.8.10 fix as soon as possible.

Is there anything else we should know?
======================================
Here's the text of the release:

*** CVE-2016-2512: Malicious redirect and possible XSS attack via user-supplied redirect URLs containing basic auth

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 check for these redirects (namely django.utils.http.is_safe_url()) considered some URLs with basic authentication credentials "safe" when they shouldn't be.

For example, a URL like http://mysite.example.com\@attacker.com would be considered safe if the request's host is http://mysite.example.com, but redirecting to this URL sends the user to attacker.com.

Also, 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.

Thanks Mark Striemer for reporting the issue.

*** CVE-2016-2513: User enumeration through timing difference on password hasher work factor upgrade

In each major version of Django since 1.6, the default number of iterations for the PBKDF2PasswordHasher and its subclasses has increased. This improves the security of the password as the speed of hardware increases, however, it also creates a timing difference between a login request for a user with a password encoded in an older number of iterations and login request for a nonexistent user (which runs the default hasher's default number of iterations since Django 1.6).

This only affects users who haven't logged in since the iterations were increased. The first time a user logs in after an iterations increase, their password is updated with the new iterations and there is no longer a timing difference.

The new BasePasswordHasher.harden_runtime() method allows hashers to bridge the runtime gap between the work factor (e.g. iterations) supplied in existing encoded passwords and the default work factor of the hasher. This method is implemented for PBKDF2PasswordHasher and BCryptPasswordHasher. The number of rounds for the latter hasher hasn't changed since Django 1.4, but some projects may subclass it and increase the work factor as needed.

A warning will be emitted for any third-party password hashers that don't implement a harden_runtime() method.

If you have different password hashes in your database (such as SHA1 hashes from users who haven't logged in since the default hasher switched to PBKDF2 in Django 1.4), the timing difference on a login request for these users may be even greater and this fix doesn't remedy that difference (or any difference when changing hashers). You may be able to upgrade those hashes to prevent a timing attack for that case.

Thanks Sjoerd Job Postmus for reporting the issue.

Comment 1

[Rob Hudson [:robhudson]]

Fixed in:
https://github.com/mozilla/kuma/commit/a07b2e803a942cd8c3b4e15afc981ab5fbc61922

r=willkg

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.