New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fully deprecate textual coercion in where(), filter(), order_by(), add docnotes not to pass untrusted input to thsee #4481
Comments
|
hi there - why do you consider order_by() to be something that would receive untrusted user input? Please be specific why these are not also CVEs: Mitigations for "SQL injection" deal completely with statement parameters (see https://en.wikipedia.org/wiki/SQL_injection#Mitigation), and not the syntax of the statement itself. SQL injection is not expected to be a vulnerability at the syntax level. All elements of the select() object accept plain SQL as an argument which is assumed to be programmatic input. This has been the explicit contract of these methods for many years. In recent versions they emit a warning when the coercion to text() occurs, but we haven't created a formal deprecation schedule, although the 1.3 series is a good place to do that (see #4393). But we can't just take it out retroactively because it would break existing code. We can certainly add documentation and make the warning messages more dire, but I wonder why Python's own docs at https://docs.python.org/3/library/functions.html#exec say nothing similar for exec(). |
|
1、In some website, developers use dynamic sort operation like this
2、If we don't remid developers the potential risks of using untrusted input at order_by ,sql injection may occur. |
|
never trust input data |
It is truth. |
|
the steps to take here are:
|
in a front-end JS framework, EVERYTHING is untrusted user input. The source code can be directly rewritten by a hostile application in an adjoining window. There's no comparison between a front-end framework guarding against XSS, which can literally be anywhere, and a database driver that must ensure that parameters are bound. |
|
I've googled a few flask tutorials and the official flask documentation and all examples of order_by() illustrate an ORM-mapped column object being passed in, no strings. People generally don't even know these methods accept strings. |
flask sqlalchemy also has this problem https://github.com/21k/sqlalchemy/blob/master/flask/__init__.py |
|
Mike Bayer has proposed a fix for this issue in the master branch: Remove all remaining text() coercions https://gerrit.sqlalchemy.org/1126 |
|
hi did you also submit CVE-2019-7548 ? why is there no bug for that one here? |
not me |
|
well, you and whoever else posted that CVE have lit up the whole internet so just the group_by and order_by being blocked I think I should just release in 1.2.19. |
|
I see that Debian LTS and RHEL 7 ship sqlalchemy-0.9.8, and both mark it as vulnerable (it is). |
|
0.9.8 is EOL for many years on the upstream side. RHEL will be porting patches internally (UPDATE: they are "wontfix"). All the tests that assume this functionality need to be changed or removed. It will also cause breakage for any applications that are dependent on the behavior. |
|
to patch the CVEs you only need: this line: 30307c4#diff-9deda8c7c10c7034cd9463f530ca81f0R769 and this method: 30307c4#diff-e9e388f99dea16cf0a1ad8f227cf6920R4495 nothing else is part of the CVE. |
|
Hmmm, 0.9.8 lacks |
|
they are assigned to me so sometime in the coming weeks, but if the change is too involved in the 0.9 series if might not be worth it. note these "CVEs" are against an API feature that has been part of SQLAlchemy's tutorial for over ten years - all components of the select() construct accept plain text. Only in 1.0 was it changed to favor the use of text() over plain string and a warning was emitted if text() was omitted. |
|
Thanks a lot for the detailed feedback! |
|
Mike Bayer referenced this issue: Illustrate fix for #4481 in terms of an 0.9 patch https://gerrit.sqlalchemy.org/1165 |
|
Alrighty, the 0.9 version is illustrated at https://gerrit.sqlalchemy.org/1165. There is the significant caveat that it breaks compatibility with the textual use case, that is It also breaks compatibility with a subset of that feature that is still supported today, which is where with this patch, none of the above features are allowed and a blanket exception is raised requesting that the text() construct be used, e.g. |
|
Hi! I tested f128dd6.diff.base64 and it seems the POC still works though: (I expected something like The test suite ( |
|
0.9 does this more crappily, missed a few, one moment |
|
OK please see patch set 2 at https://gerrit.sqlalchemy.org/1165 |
|
The POCs are now blocked. |
|
FYI we just had our first official "someone was relying on this behavior" report in #4538, depite that it's been emitting a warning for four years, so this might break a very small portion of downstream applications |
|
Mike Bayer referenced this issue: Illustrate fix for #4481 in terms of a 1.2 patch https://gerrit.sqlalchemy.org/1184 |
|
I was hoping to find a gaping hole in SQLa, instead I see a wannabe sec researcher trying to make a name for himself. Boooo. Sorry for off-topic. |
|
Will there be any mechanism for whitelisting some functions? I'm using clickhouse with parametric functions. In version 1.2, I can use |
|
here is a new hack, however, it is not guaranteed to remain functioning, since this is overall not how func was intended to be used: we right now don't have a built-in construct for a first-class SQL function like that, the most legit way to implement this in your project would be to use @compiles with GenericFunction: |
|
I find the MR (https://gerrit.sqlalchemy.org/c/sqlalchemy/sqlalchemy/+/1184/) is abandoned, So how do you fix this bug in the rel_1_2 branch?@zzzeek |
|
1.2 is EOL. if you are stuck on 1.2, use the warnings filter to promote the warning to an error. |
Can I use the patch (https://gerrit.sqlalchemy.org/c/sqlalchemy/sqlalchemy/+/1184/ ) to fix CVE-2019-7164 and CVE-2019-7548 ? I use sqlalchemy 1.2.19. |
|
sure |
ok, thanks for your quick reply |
@zzzeek
1、SQLAlchemy through 1.2.17 and 1.3.x through 1.3.0b2 allows SQL Injection via the order_by parameter.
2、exp
---------------------------------
python dal.py 'if(1=1,create_time,username)'
python dal.py 'if(1=2,create_time,username)'
python dal.py 'create_time'
---------------------------------
3、reserved by CVE-2019-7164
The text was updated successfully, but these errors were encountered: