Multiple security flaws have been recently addressed in the v1.3.1 and v1.2.7 versions of the Django Python Web framework: 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 Reproducible: Always
@python is =dev-python/django-1.3.1 a suitable target for stabilization?
That should be fine, yes.
(In reply to comment #2) > That should be fine, yes. Great, thanks. Arches, please test and mark stable: =dev-python/django-1.3.1 Target keywords : "amd64 x86"
amd64 ok chack also for bug 382611 and bug 367547
x86 stable
emerges ok. all use flags, ok. Neither of you mentioned test phase failure. bug 371057. Failed with both python 2 and 3 set. Perhaps because it's no regression, so out of contention to stop stabalisation.
+ 16 Sep 2011; Tony Vroon <chainsaw@gentoo.org> django-1.3.1.ebuild: + Marked stable on AMD64 based on arch testing by Agostino "ago" Sarubbo & Ian + "idella4" Delaney in security bug #382599 filed by Sean Amoss. Security, please proceed with GLSA voting.
Vote: NO
GLSA Vote: No too. Closing noglsa.
*** Bug 387665 has been marked as a duplicate of this bug. ***
CVE-2011-4140 (http://nvd.nist.gov/nvd.cfm?cvename=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. CVE-2011-4139 (http://nvd.nist.gov/nvd.cfm?cvename=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. CVE-2011-4138 (http://nvd.nist.gov/nvd.cfm?cvename=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. CVE-2011-4137 (http://nvd.nist.gov/nvd.cfm?cvename=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. CVE-2011-4136 (http://nvd.nist.gov/nvd.cfm?cvename=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.