Bug 913042 (CVE-2013-0306) - CVE-2013-0306 Django: Formset denial-of-service
Summary: CVE-2013-0306 Django: Formset denial-of-service
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2013-0306
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 913043 913044 913045 913048 913050 913054 1005404
Blocks: 916886
TreeView+ depends on / blocked
 
Reported: 2013-02-20 09:31 UTC by Kurt Seifried
Modified: 2019-09-29 13:01 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-04-12 22:03:51 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2013:0670 0 normal SHIPPED_LIVE Moderate: Django security update 2013-03-21 22:12:01 UTC

Description Kurt Seifried 2013-02-20 09:31:17 UTC
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 09:33:55 UTC
Created Django tracking bugs for this issue

Affects: epel-5 [bug 913043]

Comment 2 Kurt Seifried 2013-02-20 09:36:53 UTC
Created Django14 tracking bugs for this issue

Affects: epel-6 [bug 913045]

Comment 3 Kurt Seifried 2013-02-20 09:36:56 UTC
Created Django tracking bugs for this issue

Affects: epel-6 [bug 913044]

Comment 4 Kurt Seifried 2013-02-20 09:39:05 UTC
Created Django tracking bugs for this issue

Affects: fedora-17 [bug 913048]

Comment 7 Fedora Update System 2013-03-11 19:32:54 UTC
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 08:49:52 UTC
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 08:53:59 UTC
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 18:12:51 UTC
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.