[1.9.x] Fixed CVE-2016-9014 -- Validated Host header when DEBUG=True.

This is a security fix.

2 files changed, 44 insertions, 0 deletions

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
+<http://benmmurphy.github.io/blog/2016/07/11/rails-webconsole-dns-rebinding/>`_.
+
+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
+<http://benmmurphy.github.io/blog/2016/07/11/rails-webconsole-dns-rebinding/>`_.
+
+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.