Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 536586 (CVE-2015-0219) - <dev-python/django-(1.4.18,1.6.10,1.7.3): multiple vulnerabilities (CVE-2015-{0219,0220,0221,0222})
Summary: <dev-python/django-(1.4.18,1.6.10,1.7.3): multiple vulnerabilities (CVE-2015-...
Alias: CVE-2015-0219
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal minor (vote)
Assignee: Gentoo Security
Whiteboard: B3 [noglsa]
Depends on: 541704
  Show dependency tree
Reported: 2015-01-14 11:56 UTC by Agostino Sarubbo
Modified: 2015-03-01 14:42 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Agostino Sarubbo gentoo-dev 2015-01-14 11:56:02 UTC
From ${URL} :

Today the Django team is issuing multiple releases -- Django 1.4.18, Django 1.6.10, and Django 1.7.3 -- as part of our security process. These releases are now available on PyPI and our download page.

These releases address several security issues. We encourage all users of Django to upgrade as soon as possible.

Issue: WSGI header spoofing via underscore/dash conflation

When HTTP headers are placed into the WSGI environ, they are normalized by converting to uppercase, converting all dashes to underscores, and prepending HTTP_. For instance, a header X-Auth-User would become HTTP_X_AUTH_USER in the WSGI environ (and thus also in 
Django's request.META dictionary).

Unfortunately, this means that the WSGI environ cannot distinguish between headers containing dashes and headers containing underscores: X-Auth-User and X-Auth_User both become HTTP_X_AUTH_USER. This means that if a header is used in a security-sensitive way (for 
instance, passing authentication information along from a front-end proxy), even if the proxy carefully strips any incoming value for X-Auth-User, an attacker may be able to provide an X-Auth_User header (with underscore) and bypass this protection.

In order to prevent such attacks, both Nginx and Apache 2.4+ strip all headers containing underscores from incoming requests by default. Django's built-in development server now does the same. Django's development server is not recommended for production use, but 
matching the behavior of common production servers reduces the surface area for behavior changes during deployment.

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

Thanks to Jedediah Smith for reporting the issue.

Issue: 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.util.http.is_safe_url()) didn't strip leading whitespace on the tested 
URL and as such considered URLs like \njavascript:... safe. If a developer relied on is_safe_url() to provide safe redirect targets and put such a URL into a link, they could suffer from a XSS attack. This bug doesn't affect Django currently, since we only put 
this URL into the Location response header and browsers seem to ignore JavaScript there.

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

Thanks to Mikko Ohtamaa for reporting the issue.

Issue: Denial-of-service attack against django.views.static.serve

In older versions of Django, the django.views.static.serve() view read the files it served one line at a time. Therefore, a big file with no newlines would result in memory usage equal to the size of that file. An attacker could exploit this and launch a 
denial-of-service attack by simultaneously requesting many large files. This view now reads the file in chunks to prevent large memory usage.

Note, however, that this view has always carried a warning that it is not hardened for production use and should be used only as a development aid. Now may be a good time to audit your project and serve your files in production using a real front-end web server 
if you are not doing so.

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

Thanks Alex Gaynor for reporting the issue.

Issue: Database denial-of-service with ModelMultipleChoiceField

Given a form that uses ModelMultipleChoiceField and show_hidden_initial=True (not a documented API), it was possible for a user to cause an unreasonable number of SQL queries by submitting duplicate values for the field's data. The validation logic in 
ModelMultipleChoiceField now deduplicates submitted values to address this issue.

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

Thanks Keryn Knight for reporting the issue.

Affected versions

Django master development branch (currently at pre-alpha status) (except the serve() denial of service issue)
Django 1.7
Django 1.6
Django 1.4 [Long-term support] (except the ModelMultipleChoiceField issue)

@maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
Comment 1 GLSAMaker/CVETool Bot gentoo-dev 2015-02-13 17:44:57 UTC
CVE-2015-0222 (
  ModelMultipleChoiceField in Django 1.6.x before 1.6.10 and 1.7.x before
  1.7.3, when show_hidden_initial is set to True, allows remote attackers to
  cause a denial of service by submitting duplicate values, which triggers a
  large number of SQL queries.

CVE-2015-0221 (
  The django.views.static.serve view in Django before 1.4.18, 1.6.x before
  1.6.10, and 1.7.x before 1.7.3 reads files an entire line at a time, which
  allows remote attackers to cause a denial of service (memory consumption)
  via a long line in a file.

CVE-2015-0220 (
  The django.util.http.is_safe_url function in Django before 1.4.18, 1.6.x
  before 1.6.10, and 1.7.x before 1.7.3 does not properly handle leading
  whitespaces, which allows remote attackers to conduct cross-site scripting
  (XSS) attacks via a crafted URL, related to redirect URLs, as demonstrated
  by a "\njavascript:" URL.

CVE-2015-0219 (
  Django before 1.4.18, 1.6.x before 1.6.10, and 1.7.x before 1.7.3 allows
  remote attackers to spoof WSGI headers by using an _ (underscore) character
  instead of a - (dash) character in an HTTP header, as demonstrated by an
  X-Auth_User header.
Comment 2 Justin Lecher (RETIRED) gentoo-dev 2015-02-28 13:14:40 UTC
+  28 Feb 2015; Justin Lecher <> package.mask:
+  Mask dev-python/django-1.5* for unfixed security issues
+  (CVE-2015-{0219,0220,0221,0222}), #536586
Comment 3 Justin Lecher (RETIRED) gentoo-dev 2015-02-28 18:09:30 UTC
*django-1.4.19 (28 Feb 2015)
+*django-1.6.10 (28 Feb 2015)
+  28 Feb 2015; Justin Lecher <> +django-1.4.19.ebuild,
+  +django-1.6.10.ebuild, +files/django-1.4.19-bashcomp.patch,
+  +files/django-1.4.19-test.patch, +files/django-1.6.10-bashcomp.patch,
+  +files/django-1.6.10-test.patch, -django-1.7.4.ebuild, -django-1.7.ebuild,
+  django-1.7.5.ebuild, django-9999.ebuild:
+  Version BUmp and drop old for CVE-2015-{0219,0220,0221,0222}, #536586; add
+  correct dependencies for tests, Use optfeature instead of harddepened on
+  imaging, #473228
Comment 4 Justin Lecher (RETIRED) gentoo-dev 2015-02-28 18:10:23 UTC
@arches please stable, testsuite included

Comment 5 Agostino Sarubbo gentoo-dev 2015-03-01 11:22:21 UTC
amd64 stable
Comment 6 Agostino Sarubbo gentoo-dev 2015-03-01 11:22:55 UTC
x86 stable.

Maintainer(s), please cleanup.
Security, please vote.
Comment 7 Yury German Gentoo Infrastructure gentoo-dev 2015-03-01 14:05:55 UTC
Arches, Thank you for your work.
GLSA Vote: No

Maintainer(s), please drop the vulnerable version(s).
Comment 8 Kristian Fiskerstrand (RETIRED) gentoo-dev 2015-03-01 14:08:33 UTC
GLSA Vote: No
Comment 9 Justin Lecher (RETIRED) gentoo-dev 2015-03-01 14:37:39 UTC
All vulnerable versions dropped.
Comment 10 Kristian Fiskerstrand (RETIRED) gentoo-dev 2015-03-01 14:42:04 UTC
(In reply to Justin Lecher from comment #9)
> All vulnerable versions dropped.