Multiple security flaws have been recently addressed in the v1.3.1 and v1.2.7 versions of the Django Python Web framework (from [1]): 1, Session manipulation, 2, Denial of service attack via URLField, 3, URLField redirection, 4, Host header cache poisoning, 5, Host header and CSRF, 6, Cross-subdomain CSRF attacks, 7, DEBUG pages and sensitive POST data References: [1] https://www.djangoproject.com/weblog/2011/sep/09/
Created attachment 522611 [details] Local text copy of Django upstream archive post from 2011-09-09
CVE(s) Request: [2] http://www.openwall.com/lists/oss-security/2011/09/11/1
These issues are scheduled to be addressed in the following releases for Fedora: 1) Django-1.3.1-2.fc14 for Fedora-14, 2) Django-1.3.1-2.fc15 for Fedora-15, and in the following release for EPEL-6: 3) Django-1.2.6-2.el6 The above updates has been pushed to Fedora -testing repository and once they have passed the required testing, they will be pushed to -stable repository.
Please use Django 1.2.7; the patch was not applied in the 1.2.6 release: https://www.djangoproject.com/weblog/2011/sep/10/127/
Are there tracking bugs for these specific distributions? I'm interested in the fix for EPEL, and I'd like to help with the testing if possible.
Created Django tracking bugs for this issue Affects: epel-6 [bug 742466]
Hi Brian, (In reply to comment #5) > Are there tracking bugs for these specific distributions? No there aren't particular Fedora release specific bugs (since the updates were scheduled sooner than this main bug existed). > I'm interested in > the fix for EPEL, and I'd like to help with the testing if possible. But looks the latest version in EPEL-6 is still Django-v1.2.6 based, thus created new one (previous comment) to ensure update to v1.2.7. Hope this helps, Jan.
The CVE identifiers: CVE-2011-4136, CVE-2011-4137, CVE-2011-4138, CVE-2011-4139, CVE-2011-4140 with the following description have been assigned to these issues by Common Vulnerabilities and Exposures: 1) * Name: CVE-2011-4136: django.contrib.sessions in Django before 1.2.7 and 1.3.x before 1.3.1, when session data is stored in the cache, uses the root namespace for both session identifiers and application-data keys, which allows remote attackers to modify a session by triggering use of a key that is equal to that session's identifier. References: [1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4136 [2] http://openwall.com/lists/oss-security/2011/09/11/1 [3] http://openwall.com/lists/oss-security/2011/09/13/2 [4] https://www.djangoproject.com/weblog/2011/sep/09/ [5] https://www.djangoproject.com/weblog/2011/sep/10/127/ 2) * Name: CVE-2011-4137: The verify_exists functionality in the URLField implementation in Django before 1.2.7 and 1.3.x before 1.3.1 relies on Python libraries that attempt access to an arbitrary URL with no timeout, which allows remote attackers to cause a denial of service (resource consumption) via a URL associated with (1) a slow response, (2) a completed TCP connection with no application data sent, or (3) a large amount of application data, a related issue to CVE-2011-1521. References: [6] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4137 [7] http://openwall.com/lists/oss-security/2011/09/11/1 [8] http://openwall.com/lists/oss-security/2011/09/13/2 [9] http://openwall.com/lists/oss-security/2011/09/15/5 [10] https://www.djangoproject.com/weblog/2011/sep/09/ [11] https://www.djangoproject.com/weblog/2011/sep/10/127/ 3) * Name: CVE-2011-4138: The verify_exists functionality in the URLField implementation in Django before 1.2.7 and 1.3.x before 1.3.1 originally tests a URL's validity through a HEAD request, but then uses a GET request for the new target URL in the case of a redirect, which might allow remote attackers to trigger arbitrary GET requests with an unintended source IP address via a crafted Location header. References: [12] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4138 [13] http://openwall.com/lists/oss-security/2011/09/11/1 [14] http://openwall.com/lists/oss-security/2011/09/13/2 [15] https://www.djangoproject.com/weblog/2011/sep/09/ [16] https://www.djangoproject.com/weblog/2011/sep/10/127/ 4) * Name: CVE-2011-4139: Django before 1.2.7 and 1.3.x before 1.3.1 uses a request's HTTP Host header to construct a full URL in certain circumstances, which allows remote attackers to conduct cache poisoning attacks via a crafted request. References: [17] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4139 [18] http://openwall.com/lists/oss-security/2011/09/11/1 [19] http://openwall.com/lists/oss-security/2011/09/13/2 [20] https://www.djangoproject.com/weblog/2011/sep/09/ [21] https://www.djangoproject.com/weblog/2011/sep/10/127/ 5) * Name: CVE-2011-4140: The CSRF protection mechanism in Django through 1.2.7 and 1.3.x through 1.3.1 does not properly handle web-server configurations supporting arbitrary HTTP Host headers, which allows remote attackers to trigger unauthenticated forged requests via vectors involving a DNS CNAME record and a web page containing JavaScript code. References: [22] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4140 [23] http://openwall.com/lists/oss-security/2011/09/11/1 [24] http://openwall.com/lists/oss-security/2011/09/13/2 [25] https://www.djangoproject.com/weblog/2011/sep/09/ [26] https://www.djangoproject.com/weblog/2011/sep/10/127/
This has been addressed in Fedora/EPEL: fedora:19/python-django14-1.4.13-1.fc19 fedora:19/python-django-1.5.8-1.fc19 fedora:20/python-django-1.6.5-1.fc20 fedora:20/python-django14-1.4.13-1.fc20 fedora:20/python-django15-1.5.8-4.fc20 fedora:epel:6/Django14-1.4.13-1.el6 fedora:epel:6/python-django15-1.5.6-1.el6 fedora:epel:7/python-django15-1.5.6-1.el7 fedora:epel:7/python-django-1.6.5-1.el7