[1.7.x] Prevented newlines from being accepted in some validators.

This is a security fix; disclosure to follow shortly.

Thanks to Sjoerd Job Postmus for the report and draft patch.

2 files changed, 54 insertions, 0 deletions

diff --git a/docs/releases/1.4.21.txt b/docs/releases/1.4.21.txt
index da69b26564..477f9a722c 100644
--- a/docs/releases/1.4.21.txt
+++ b/docs/releases/1.4.21.txt
@@ -26,3 +26,29 @@ As each built-in session backend was fixed separately (rather than a fix in the
 core sessions framework), maintainers of third-party session backends should
 check whether the same vulnerability is present in their backend and correct
 it if so.
+
+Header injection possibility since validators accept newlines in input
+======================================================================
+
+Some of Django's built-in validators
+(``django.core.validators.EmailValidator``, most seriously) didn't
+prohibit newline characters (due to the usage of ``$`` instead of ``\Z`` in the
+regular expressions). If you use values with newlines in HTTP response or email
+headers, you can suffer from header injection attacks. Django itself isn't
+vulnerable because :class:`~django.http.HttpResponse` and the mail sending
+utilities in :mod:`django.core.mail` prohibit newlines in HTTP and SMTP
+headers, respectively. While the validators have been fixed in Django, if
+you're creating HTTP responses or email messages in other ways, it's a good
+idea to ensure that those methods prohibit newlines as well. You might also
+want to validate that any existing data in your application doesn't contain
+unexpected newlines.
+
+:func:`~django.core.validators.validate_ipv4_address`,
+:func:`~django.core.validators.validate_slug`, and
+:class:`~django.core.validators.URLValidator` and their usage in the
+corresponding form fields ``GenericIPAddresseField``, ``IPAddressField``,
+``SlugField``, and ``URLField`` are also affected.
+
+The undocumented, internally unused ``validate_integer()`` function is now
+stricter as it validates using a regular expression instead of simply casting
+the value using ``int()`` and checking if an exception was raised.
diff --git a/docs/releases/1.7.9.txt b/docs/releases/1.7.9.txt
index f402a4cdd5..48a4fd3bd2 100644
--- a/docs/releases/1.7.9.txt
+++ b/docs/releases/1.7.9.txt
@@ -27,6 +27,34 @@ core sessions framework), maintainers of third-party session backends should
 check whether the same vulnerability is present in their backend and correct
 it if so.
 
+Header injection possibility since validators accept newlines in input
+======================================================================
+
+Some of Django's built-in validators
+(``django.core.validators.EmailValidator``, most seriously) didn't
+prohibit newline characters (due to the usage of ``$`` instead of ``\Z`` in the
+regular expressions). If you use values with newlines in HTTP response or email
+headers, you can suffer from header injection attacks. Django itself isn't
+vulnerable because :class:`~django.http.HttpResponse` and the mail sending
+utilities in :mod:`django.core.mail` prohibit newlines in HTTP and SMTP
+headers, respectively. While the validators have been fixed in Django, if
+you're creating HTTP responses or email messages in other ways, it's a good
+idea to ensure that those methods prohibit newlines as well. You might also
+want to validate that any existing data in your application doesn't contain
+unexpected newlines.
+
+:func:`~django.core.validators.validate_ipv4_address`,
+:func:`~django.core.validators.validate_slug`, and
+:class:`~django.core.validators.URLValidator` are also affected, however, as
+of Django 1.6 the ``GenericIPAddresseField``, ``IPAddressField``, ``SlugField``,
+and ``URLField`` form fields which use these validators all strip the input, so
+the possibility of newlines entering your data only exists if you are using
+these validators outside of the form fields.
+
+The undocumented, internally unused ``validate_integer()`` function is now
+stricter as it validates using a regular expression instead of simply casting
+the value using ``int()`` and checking if an exception was raised.
+
 Bugfixes
 ========