Django/django
11
0
Fork 0
Code Pull Requests Projects Releases Activity

[1.4.x] Update 1.4.4 release notes for all security fixes.

Browse Source
This commit is contained in:
Carl Meyer 2013-02-12 15:33:38 -07:00
parent 0cc350a896
commit 62d5338bf2
1 changed files with 51 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

52
docs/releases/1.4.4.txt
View File

@ -4,8 +4,13 @@ Django 1.4.4 release notes
*February 19, 2013*
Django 1.4.4 fixes four security issues present in previous Django releases in
the 1.4 series, as well as several other bugs and numerous documentation
improvements.
This is the fourth bugfix/security release in the Django 1.4 series.
Host header poisoning
---------------------
@ -24,16 +29,61 @@ Host header not matching an entry in this list will raise
``SuspiciousOperation`` if ``request.get_host()`` is called. For full details
see the documentation for the :setting:`ALLOWED_HOSTS` setting.
The default value for this setting in Django 1.4.4 is `['*']` (matching any
The default value for this setting in Django 1.4.4 is ``['*']`` (matching any
host), for backwards-compatibility, but we strongly encourage all sites to set
a more restrictive value.
This host validation is disabled when ``DEBUG`` is ``True`` or when running tests.
XML deserialization
-------------------
The XML parser in the Python standard library is vulnerable to a number of
denial-of-service attacks via external entities and entity expansion. Django
uses this parser for deserializing XML-formatted database fixtures. This
deserializer is not intended for use with untrusted data, but in order to err
on the side of safety in Django 1.4.4 the XML deserializer refuses to parse an
XML document with a DTD (DOCTYPE definition), which closes off these attack
avenues.
These issues in the Python standard library are CVE-2013-1664 and
CVE-2013-1665. More information available `from the Python security team`_.
Django's XML serializer does not create documents with a DTD, so this should
not cause any issues with the typical round-trip from ``dumpdata`` to
``loaddata``, but if you feed your own XML documents to the ``loaddata``
management command, you will need to ensure they do not contain a DTD.
.. _from the Python security team: http://blog.python.org/2013/02/announcing-defusedxml-fixes-for-xml.html
Formset memory exhaustion
-------------------------
Previous versions of Django did not validate or limit the form-count data
provided by the client in a formset's management form, making it possible to
exhaust a server's available memory by forcing it to create very large numbers
of forms.
In Django 1.4.4, all formsets have a strictly-enforced maximum number of forms
(1000 by default, though it can be set higher via the ``max_num`` formset
factory argument).
Admin history view information leakage
--------------------------------------
In previous versions of Django, an admin user without change permission on a
model could still view the unicode representation of instances via their admin
history log. Django 1.4.4 now limits the admin history log view for an object
to users with change permission for that model.
Other bugfixes and changes
==========================
* Prevented transaction state from leaking from one request to the next (#19707).
* Changed a SQL command syntax to be MySQL 4 compatible (#19702).
* Added backwards-compatibility with old unsalted MD5 passwords (#18144).
* Numerous documentation improvements and fixes.