Bug 913037

Summary: Django: Host header poisoning hardening
Product: [Other] Security Response Reporter: Kurt Seifried <kseifried>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: apevec, apevec, cpelland, dmalcolm, markmc, michel, mrunge, rbryant, rhos-maint, smilner
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: impact=low,public=20130219,reported=20130219,source=upstream,cvss2=0.0/AV:N/AC:L/Au:N/C:N/I:N/A:N,epel-5/Django=affected,epel-6/Django=affected,epel-6/Django14=affected,fedora-17/Django=affected,openstack-1/Django=affected,openstack-2.1/Django14=affected
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-06-07 14:56:33 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On: 913043, 913044, 913045, 913048, 913050, 913054    
Bug Blocks: 916886    

Description Kurt Seifried 2013-02-20 04:23:57 EST
James Bennett of Django reports:

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.

Since this is hardening/tightening of a previous issue, it does not have a new CVE number.

External reference:
https://www.djangoproject.com/weblog/2013/feb/19/security/
Comment 1 Kurt Seifried 2013-02-20 04:32:56 EST
Created Django tracking bugs for this issue

Affects: epel-5 [bug 913043]
Comment 2 Kurt Seifried 2013-02-20 04:34:52 EST
Created Django14 tracking bugs for this issue

Affects: epel-6 [bug 913045]
Comment 3 Kurt Seifried 2013-02-20 04:34:56 EST
Created Django tracking bugs for this issue

Affects: epel-6 [bug 913044]
Comment 4 Kurt Seifried 2013-02-20 04:37:45 EST
Created Django tracking bugs for this issue

Affects: fedora-17 [bug 913048]
Comment 7 Fedora Update System 2013-03-11 15:32:21 EDT
Django14-1.4.5-1.el6 has been pushed to the Fedora EPEL 6 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 8 Fedora Update System 2013-03-12 04:49:21 EDT
python-django-1.4.5-2.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 9 Fedora Update System 2013-03-12 04:53:29 EDT
Django-1.4.5-1.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 10 errata-xmlrpc 2013-03-21 14:12:35 EDT
This issue has been addressed in following products:

  OpenStack Folsom for RHEL 6

Via RHSA-2013:0670 https://rhn.redhat.com/errata/RHSA-2013-0670.html
Comment 11 Matthias Runge 2013-06-07 14:56:33 EDT
Since all dependent bugs are fixed, I guess, I can close this one, too?