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
This is somewhat public now via OpenStack committing the following: https://github.com/openstack/keystone/commit/45b36369a39e5e3cde6453312d73f85268dcd372%0A
Lifting embargo. This was fixed upstream in 0.6.7 and 0.7.0b4.
Created python-sqlalchemy tracking bugs for this issue Affects: epel-5 [bug 800936]
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
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.
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.
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.
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.
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.