This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 783305 - (CVE-2012-0805) CVE-2012-0805 python-sqlalchemy: SQL injection flaw due to not checking LIMIT input for correct type
CVE-2012-0805 python-sqlalchemy: SQL injection flaw due to not checking LIMIT...
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=20120307,repor...
: Security
Depends On: 784365 784366 800936
Blocks: 783486
  Show dependency treegraph
 
Reported: 2012-01-19 16:52 EST by Vincent Danen
Modified: 2015-11-24 09:46 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-04-01 16:21:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Vincent Danen 2012-01-19 16:52:39 EST
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 00:11:19 EST
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 08:55:51 EST
Lifting embargo.  This was fixed upstream in 0.6.7 and 0.7.0b4.
Comment 11 Tomas Hoger 2012-03-07 09:17:03 EST
Created python-sqlalchemy tracking bugs for this issue

Affects: epel-5 [bug 800936]
Comment 12 errata-xmlrpc 2012-03-07 09:26:46 EST
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 13:55:31 EDT
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 13:55:42 EDT
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 18:57:02 EDT
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 18:57:41 EDT
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-11 23:06:34 EDT
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.

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