Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 598770 (CVE-2016-9013, CVE-2016-9014, CVE-2017-7233, CVE-2017-7234)

Summary: <dev-python/django-{1.8.18,1.9.13,1.10.7}: multiple vulnerabilities (CVE-2016-{9013,9014},CVE-2017-{7233,7234})
Product: Gentoo Security Reporter: Agostino Sarubbo <ago>
Component: VulnerabilitiesAssignee: Gentoo Security <security>
Status: RESOLVED FIXED    
Severity: minor CC: jlec, python
Priority: Normal Flags: stable-bot: sanity-check+
Version: unspecified   
Hardware: All   
OS: Linux   
URL: https://www.djangoproject.com/weblog/2016/nov/01/security-releases/
Whiteboard: B3 [noglsa cve ]
Package list:
dev-python/django-1.8.18
Runtime testing required: ---
Bug Depends on:    
Bug Blocks: 576876, 589134, 595544    

Description Agostino Sarubbo gentoo-dev 2016-11-02 11:01:57 UTC
From ${URL} :

Django security releases issued: 1.10.3, 1.9.11 and 1.8.16

Posted by Tim Graham on Novembre 1, 2016
In accordance with our security release policy, the Django team released Django 1.10.3, Django 1.9.11, and 1.8.16. These releases addresses two security issues detailed below. We encourage all users of Django to upgrade as soon as possible.

CVE-2016-9013: User with hardcoded password created when running tests on Oracle

When running tests with an Oracle database, Django creates a temporary database user. In older versions, if a password isn't manually specified in the database settings TEST dictionary, a hardcoded password is used. This could allow an attacker with network 
access to the database server to connect.

This user is usually dropped after the test suite completes, but not when using the manage.py test --keepdb option or if the user has an active session (such as an attacker's connection).

A randomly generated password is now used for each test run.

Thanks Marti Raudsepp for reporting the issue.

CVE-2016-9014: DNS rebinding vulnerability when DEBUG=True

Older versions of Django don't validate the Host header against settings.ALLOWED_HOSTS when settings.DEBUG=True. This makes them vulnerable to a DNS rebinding attack.

While Django doesn't ship a module that allows remote code execution, this is at least a cross-site scripting vector, which could be quite serious if developers load a copy of the production database in development or connect to some production services for which 
there's no development instance, for example. If a project uses a package like the django-debug-toolbar, then the attacker could execute arbitrary SQL, which could be especially bad if the developers connect to the database with a superuser account.

settings.ALLOWED_HOSTS is now validated regardless of DEBUG. For convenience, if ALLOWED_HOSTS is empty and DEBUG=True, the following variations of localhost are allowed ['localhost', '127.0.0.1', '::1']. If your local settings file has your production 
ALLOWED_HOSTS value, you must now omit it to get those fallback values.

Thanks Aymeric Augustin for reporting the issue.

Security Advisory: Social media fingerprinting

Along with the above security issues, we want to inform you about a "social media fingerprinting" information leakage technique that was recently disclosed.

If you enable redirect_authenticated_user on the login views, other websites will be able to determine if their visitors are authenticated on your site by requesting redirect URLs to image files on your website. To avoid this, host all images and your favicon on 
a separate domain that is not part of the ALLOWED_HOSTS.


@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 2017-01-02 07:17:18 UTC
CVE-2016-9014 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2016-9014):
  Django before 1.8.x before 1.8.16, 1.9.x before 1.9.11, and 1.10.x before
  1.10.3, when settings.DEBUG is True, allow remote attackers to conduct DNS
  rebinding attacks by leveraging failure to validate the HTTP Host header
  against settings.ALLOWED_HOSTS.

CVE-2016-9013 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2016-9013):
  Django 1.8.x before 1.8.16, 1.9.x before 1.9.11, and 1.10.x before 1.10.3
  use a hardcoded password for a temporary database user created when running
  tests with an Oracle database, which makes it easier for remote attackers to
  obtain access to the database server by leveraging failure to manually
  specify a password in the database settings TEST dictionary.
Comment 2 Manuel Rüger (RETIRED) gentoo-dev 2017-05-25 19:02:28 UTC
from: https://docs.djangoproject.com/en/1.11/releases/1.10.7/
CVE-2017-7233: Open redirect and possible XSS attack via user-supplied numeric 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 check for these redirects (namely django.utils.http.is_safe_url()) considered some numeric URLs (e.g. http:999999999) “safe” when they shouldn’t be.

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.
CVE-2017-7234: Open redirect vulnerability in django.views.static.serve()¶

A maliciously crafted URL to a Django site using the serve() view could redirect to any other domain. The view no longer does any redirects as they don’t provide any known, useful functionality.

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.
Comment 3 Manuel Rüger (RETIRED) gentoo-dev 2017-05-25 19:03:28 UTC
(In reply to Manuel Rüger from comment #2)
> from: https://docs.djangoproject.com/en/1.11/releases/1.10.7/
> CVE-2017-7233: Open redirect and possible XSS attack via user-supplied
> numeric 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 check for these redirects (namely
> django.utils.http.is_safe_url()) considered some numeric URLs (e.g.
> http:999999999) “safe” when they shouldn’t be.
> 
> 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.
> CVE-2017-7234: Open redirect vulnerability in django.views.static.serve()¶
> 
> A maliciously crafted URL to a Django site using the serve() view could
> redirect to any other domain. The view no longer does any redirects as they
> don’t provide any known, useful functionality.
> 
> 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.

CVE-2017-7234: Open redirect vulnerability in django.views.static.serve()¶

A maliciously crafted URL to a Django site using the serve() view could redirect to any other domain. The view no longer does any redirects as they don’t provide any known, useful functionality.

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.
Comment 4 GLSAMaker/CVETool Bot gentoo-dev 2017-05-26 09:07:54 UTC
CVE-2017-7234 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-7234):
  A maliciously crafted URL to a Django (1.10 before 1.10.7, 1.9 before
  1.9.13, and 1.8 before 1.8.18) site using the
  ``django.views.static.serve()`` view could redirect to any other domain, aka
  an open redirect vulnerability.

CVE-2017-7233 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-7233):
  Django 1.10 before 1.10.7, 1.9 before 1.9.13, and 1.8 before 1.8.18 relies
  on user input in some cases to redirect the user to an "on success" URL. The
  security check for these redirects (namely
  ``django.utils.http.is_safe_url()``) considered some numeric URLs "safe"
  when they shouldn't be, aka an open redirect vulnerability. 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.
Comment 5 Justin Lecher (RETIRED) gentoo-dev 2017-06-03 19:37:59 UTC
commit 6855253051c53fdcb07f62b792218550fa708bf8
Author: Justin Lecher <jlec@gentoo.org>
Date:   Sat Jun 3 20:33:58 2017 +0100

    dev-python/django: Version Bump CVE-201{6-{2512,7401,9013,9014},7-{7233,7234}}

    Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=576876
    Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=589134
    Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=595544
    Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=598770
    Package-Manager: Portage-2.3.6, Repoman-2.3.2
    Signed-off-by: Justin Lecher <jlec@gentoo.org>

    https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6855253051c53fdcb07f62b792218550fa708bf8
Comment 6 Thomas Deutschmann (RETIRED) gentoo-dev 2017-06-17 14:13:09 UTC
@ Arches,

please test and mark stable =dev-python/django-1.8.18
Comment 7 Agostino Sarubbo gentoo-dev 2017-06-17 17:24:49 UTC
x86 stable
Comment 8 Agostino Sarubbo gentoo-dev 2017-06-18 14:01:35 UTC
amd64 stable.

Maintainer(s), please cleanup.
Security, please vote.
Comment 9 Justin Lecher (RETIRED) gentoo-dev 2017-06-24 19:51:42 UTC
commit e7f02f88e81c7780c7996e7230008855e711e98e
Author: Justin Lecher <jlec@gentoo.org>
Date:   Sat Jun 24 21:44:00 2017 +0200

    dev-python/django: Drop vulnerable versions

    Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=598770
    Package-Manager: Portage-2.3.3, Repoman-2.3.2
    Signed-off-by: Justin Lecher <jlec@gentoo.org>

    https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e7f02f88e81c7780c7996e7230008855e711e98e
Comment 10 Thomas Deutschmann (RETIRED) gentoo-dev 2017-06-28 12:57:28 UTC
GLSA Vote: No

Repository is clean, all done.