Bug 783305 (CVE-2012-0805)

Summary: CVE-2012-0805 python-sqlalchemy: SQL injection flaw due to not checking LIMIT input for correct type
Product: [Other] Security Response Reporter: Vincent Danen <vdanen>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: dmalcolm, mjc, rbryant, rcvalle, security-response-team
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-04-01 20:21:32 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 784365, 784366, 800936    
Bug Blocks: 783486    

Description Vincent Danen 2012-01-19 21:52:39 UTC
Nikita Savin reported to the OpenStack security team that an SQL injection flaw existed in SQLAlchemy versions prior to 0.7.0b [1]:

  - The limit/offset keywords to select() as well
    as the value passed to select.limit()/offset()
    will be coerced to integer.  [ticket:2116]
    (also in 0.6.7)

OpenStack's keystone API did not check that the limit parameter was an integer, so would pass it on to SQLAlchemy as-is, which could result in an SQL injection attack.

The upstream fix [2] also includes unrelated Oracle fixes (for which the original bug [3] was filed), but does force any input to the limit/offset keywords is an integer.

[1] http://www.sqlalchemy.org/changelog/CHANGES_0_7_0
[2] http://www.sqlalchemy.org/trac/changeset/852b6a1a87e7/
[3] http://www.sqlalchemy.org/trac/ticket/2116

Comment 5 Vincent Danen 2012-01-25 05:11:19 UTC
This is somewhat public now via OpenStack committing the following:

https://github.com/openstack/keystone/commit/45b36369a39e5e3cde6453312d73f85268dcd372%0A

Comment 10 Tomas Hoger 2012-03-07 13:55:51 UTC
Lifting embargo.  This was fixed upstream in 0.6.7 and 0.7.0b4.

Comment 11 Tomas Hoger 2012-03-07 14:17:03 UTC
Created python-sqlalchemy tracking bugs for this issue

Affects: epel-5 [bug 800936]

Comment 12 errata-xmlrpc 2012-03-07 14:26:46 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 6

Via RHSA-2012:0369 https://rhn.redhat.com/errata/RHSA-2012-0369.html

Comment 13 Fedora Update System 2012-04-01 17:55:31 UTC
python-sqlalchemy-0.3.11-2.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 14 Fedora Update System 2012-04-01 17:55:42 UTC
python-sqlalchemy0.5-0.5.8-9.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 15 Fedora Update System 2012-04-01 22:57:02 UTC
python-sqlalchemy0.5-0.5.8-9.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 16 Fedora Update System 2012-04-01 22:57:41 UTC
python-sqlalchemy0.5-0.5.8-9.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 17 Fedora Update System 2012-04-12 03:06:34 UTC
python-sqlalchemy0.5-0.5.8-9.fc17 has been pushed to the Fedora 17 stable repository.  If problems still persist, please make note of it in this bug report.