From 7fe2d8d940fdddd1a02c4754008a27060c4a03e9 Mon Sep 17 00:00:00 2001 From: Tim Graham Date: Mon, 17 Oct 2016 12:14:49 -0400 Subject: Fixed CVE-2016-9014 -- Validated Host header when DEBUG=True. This is a security fix. --- docs/ref/settings.txt | 10 ++++++++-- docs/releases/1.10.3.txt | 22 ++++++++++++++++++++++ docs/releases/1.8.16.txt | 22 ++++++++++++++++++++++ docs/releases/1.9.11.txt | 22 ++++++++++++++++++++++ 4 files changed, 74 insertions(+), 2 deletions(-) (limited to 'docs') diff --git a/docs/ref/settings.txt b/docs/ref/settings.txt index 494988cc62..756b7bae91 100644 --- a/docs/ref/settings.txt +++ b/docs/ref/settings.txt @@ -90,8 +90,10 @@ If the ``Host`` header (or ``X-Forwarded-Host`` if list, the :meth:`django.http.HttpRequest.get_host()` method will raise :exc:`~django.core.exceptions.SuspiciousOperation`. -When :setting:`DEBUG` is ``True``, host validation is disabled; any host will -be accepted. ``ALLOWED_HOSTS`` is :ref:`checked when running tests +When :setting:`DEBUG` is ``True`` and ``ALLOWED_HOSTS`` is empty, the host +is validated against ``['localhost', '127.0.0.1', '[::1]']``. + +``ALLOWED_HOSTS`` is also :ref:`checked when running tests `. This validation only applies via :meth:`~django.http.HttpRequest.get_host()`; @@ -102,6 +104,10 @@ are bypassing this security protection. In older versions, ``ALLOWED_HOSTS`` wasn't checked when running tests. + In older versions, ``ALLOWED_HOSTS`` wasn't checked if ``DEBUG=True``. + This was also changed in Django 1.10.3, 1.9.11, and 1.8.16 to prevent a + DNS rebinding attack. + .. setting:: APPEND_SLASH ``APPEND_SLASH`` diff --git a/docs/releases/1.10.3.txt b/docs/releases/1.10.3.txt index 953544d55b..4f0b19f651 100644 --- a/docs/releases/1.10.3.txt +++ b/docs/releases/1.10.3.txt @@ -20,6 +20,28 @@ the ``manage.py test --keepdb`` option or if the user has an active session A randomly generated password is now used for each test run. +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. + Bugfixes ======== diff --git a/docs/releases/1.8.16.txt b/docs/releases/1.8.16.txt index aa5d9cccea..9cd82d8d7a 100644 --- a/docs/releases/1.8.16.txt +++ b/docs/releases/1.8.16.txt @@ -19,3 +19,25 @@ 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. + +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. diff --git a/docs/releases/1.9.11.txt b/docs/releases/1.9.11.txt index 3c29187e86..4a7b3ba086 100644 --- a/docs/releases/1.9.11.txt +++ b/docs/releases/1.9.11.txt @@ -19,3 +19,25 @@ 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. + +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. -- cgit v1.3