bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.
Please report any other irregularities here.
Created attachment 714391 [details] zip file of patches We got a security pre-notification from the Django project and a tip that Python may also release a new version addressing a vulnerability in a stdlib XML package. Both releases are expected on Tuesday, 19 February. There are 4 issues addressed in these releases (1.3.6, 1.4.4, and 1.5rc2) and upgrades need to be performed ASAP. The full notification is below. =============================================== You're receiving this message because you are on the security pre-notification list for the Django web framework; information about this list can be found in our security policy. In accordance with that policy, on Tuesday, February 19, 2013, the Django project will be issuing a set of releases to remedy several security issues reported to us. This message contains a description of the issues, a description of the changes which will be made to Django, and the patches which will be applied to Django. Issue: Host header poisoning ============================ Several previous Django security releases have attempted to address persistent issues with the HTTP ``Host`` header. Django contains code -- and some functionality shipped with Django itself makes use of that code -- for constructing a fully-qualified URL based on the incoming HTTP request. Depending on configuration, this makes use of the ``Host`` header, and so an attacker who can cause a Django application to respond to arbitrary ``Host`` headers can cause Django to generate, and display to end users, URLs on arbitrary domains. Previous iterations of this issue (see CVE-2011-4139 and CVE-2012-4520) have focused on tightening Django's parsing of ``Host`` headers, to eliminate various means by which attackers -- using techniques such as username/password pairs in their submitted ``Host`` header -- could exploit this. Ultimately, however, Django alone cannot ensure that an attacker is unable to submit, and cause Django to accept, arbitrary ``Host`` headers. Properly securing this in a deployed Django instance additionally requires configuration of the web server, and both the configuration and the achievable level of security vary with the server being used. In light of this, the ``get_host()`` method of ``django.http.HttpRequest`` will now validate the ``Host`` header against a new setting, ``ALLOWED_HOSTS``. This setting is a list of strings (by default, an empty list) corresponding to acceptable values for the header, with some support for wildcards. Code which does not use ``get_host()``, or Django configurations which can determine the current hostname without recourse to HTTP headers (i.e., when Django's sites framework is enabled) will not be affected by this change. Issue: XML entity expansion attacks =================================== Django's serialization framework includes support for serializing to, and deserializing from, XML. Django's XML deserialization is vulnerable to entity-expansion attacks. To remedy this, Django's XML deserializer will now skip processing of external entities. As this vulnerability is also present in the underlying XML-handling modules of the Python standard library, a security release of Python addressing the issue at that level is expected simultaneous with Django's release. Issue: Data leakage via admin history log ========================================= Django's bundled administrative interface keeps a log of actions taken, preserving the history of any object which is exposed through the admin interface. This history view does not perform any permission checks beyond confirming that the user has access to the administrative interface; as such, any user with admin access can view the history of any object accessible in the admin interface, and see summaries of each change made to an object. To remedy this, the admin history view for an object will now perform the same permission checks as other admin views for the same object. Issue: Formset denial-of-service when max_num not set ===================================================== Django's form library includes tools for generating formsets -- multiple instances of a single form, to be submitted simultaneously (e.g., for mass editing/updating of similar objects). Formsets allow a parameter, ``max_num``, specifying the maximum number of individual forms which may be included. The number of forms being submitted is included in a hidden field in the formset; when ``max_num`` is specified, this value is validated against ``max_num``. When ``max_num`` is not specified, however, Django accepts the submitted hidden value, and attempts to instantiate that many form objects. Sufficiently large values will result in extreme memory consumption; values exceeding ``sys.maxint`` will, in this case, result in an HTTP 500 response (due to an uncaught ``OverflowError`` from the over-large value). In either case, the result is an effective denial-of-service attack. To resolve this, Django will now supply a (suitably large) default value for ``max_num``. Application developers can still manually specify ``max_num`` to suit the needs of their applications, but absent this the default value -- 1000 -- will ensure that attackers cannot cause overflow errors or excessive memory consumption. Affected versions ================= The issues described above affect the following versions of Django: * Django master development branch * Django 1.5 release branch (soon to become Django 1.5) * Django 1.4 release branch * Django 1.3 release branch Resolution ========== Included with this email are patches implementing the changes described above, for each affected version of Django. These patches will be applied to the Django development repository on Tuesday, February 19, 2013, and the following releases will be issued along with disclosure of the reasons for these changes: * Django 1.5 release candidate 2 * Django 1.4.4 * Django 1.3.6 As Django's master development branch is currently in a pre-alpha state, and the 1.5 branch is in a pre-release state, users are strongly advised not to be running production deployments from them; the disclosure announcement will nonetheless include a reminder of this and encourage any such users to update their checkouts immediately.
This release is now public. This is a critical update. Please upgrade and deploy ASAP. https://www.djangoproject.com/weblog/2013/feb/19/security/
Grabbing this one. Should be straight-forward.
Assignee: nobody → willkg
Pushed to -stage and -prod just now.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Priority: -- → P1
Whiteboard: u=user c=site p=1 s=2013.4
Target Milestone: --- → 2013Q1
We have one instance of get_host() in kitsune/apps/ and kitsune/vendor/ (discluding django which of course has get_host() in a few places). I think this is something we need to set in the settings_local for each individual environment. e.g. -dev gets ALLOWED_HOSTS = ['support-dev.allizom.org'] Does that sound right?
Sounds right to me, yes.
https://bugzilla.mozilla.org/show_bug.cgi?id=843279 covers updating ALLOWED_HOSTS.
All set on kitsune!
These bugs are all resolved, so I'm removing the security flag from them.
You need to log in before you can comment on or make changes to this bug.