Bug 913042 - (CVE-2013-0306) CVE-2013-0306 Django: Formset denial-of-service
CVE-2013-0306 Django: Formset denial-of-service
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
impact=moderate,public=20130219,repor...
: Security
Depends On: 913043 913044 913045 913048 913050 913054 1005404
Blocks: 916886
  Show dependency treegraph
 
Reported: 2013-02-20 04:31 EST by Kurt Seifried
Modified: 2016-04-27 01:43 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-04-12 18:03:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kurt Seifried 2013-02-20 04:31:17 EST
James Bennett of Django reports:

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 displayed. A hidden input in the formset then specifies the number of forms being submitted.

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 the former case, the result is an effective denial-of-service attack. In the latter, an attacker can cause arbitrary server errors.

To resolve this, Django will now supply a (suitably large) default value for the maximum number of forms, which will be used when max_num is not supplied. 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.

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

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

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

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

Affects: fedora-17 [bug 913048]
Comment 7 Fedora Update System 2013-03-11 15:32:54 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:52 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:59 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:51 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

Note You need to log in before you can comment on or make changes to this bug.