Bug#922669: sqlalchemy: CVE-2019-7164 CVE-2019-7548 (SQL injection)

2019-05-06 Thread Ross Vandegrift
On Mon, May 06, 2019 at 10:20:25AM +0200, Thomas Goirand wrote:
> On 5/6/19 5:09 AM, Ross Vandegrift wrote:
> > Source: sqlalchemy
> > Version: 1.2.18+ds1
> > Followup-For: Bug #922669
> > 
> > I've confirmed that 1.2.18+ds1 is affected despite the description at [1].
> > Upstream has a patch for the 1.2 series at [2].
> > 
> > A debdiff including the patch is attached.  It builds and the tests pass.
> > However, the fix requires removing previously supported behavior.  Consumers
> > that depend on this have been found [3], so I'm not sure if this should be
> > shipped in buster.
> 
> Hi,
> 
> I'm sorry, but where exactly do you see a list of affected consumers?

I didn't find a list, I just wanted to note that upstream observed at
least one example (the bug report I linked as #3) of a user that was
broken by the required API change.

I don't know how concerned Debian should be about possible breakage.  I
don't use sqlalchemy much anymore, and never used the affected APIs.

Ross



Bug#922669: sqlalchemy: CVE-2019-7164 CVE-2019-7548 (SQL injection)

2019-05-06 Thread Thomas Goirand
On 5/6/19 5:09 AM, Ross Vandegrift wrote:
> Source: sqlalchemy
> Version: 1.2.18+ds1
> Followup-For: Bug #922669
> 
> I've confirmed that 1.2.18+ds1 is affected despite the description at [1].
> Upstream has a patch for the 1.2 series at [2].
> 
> A debdiff including the patch is attached.  It builds and the tests pass.
> However, the fix requires removing previously supported behavior.  Consumers
> that depend on this have been found [3], so I'm not sure if this should be
> shipped in buster.

Hi,

I'm sorry, but where exactly do you see a list of affected consumers?

Cheers,

Thomas Goirand (zigo)



Bug#922669: sqlalchemy: CVE-2019-7164 CVE-2019-7548 (SQL injection)

2019-05-05 Thread Ross Vandegrift
Source: sqlalchemy
Version: 1.2.18+ds1
Followup-For: Bug #922669

I've confirmed that 1.2.18+ds1 is affected despite the description at [1].
Upstream has a patch for the 1.2 series at [2].

A debdiff including the patch is attached.  It builds and the tests pass.
However, the fix requires removing previously supported behavior.  Consumers
that depend on this have been found [3], so I'm not sure if this should be
shipped in buster.

Ross

[1] https://github.com/sqlalchemy/sqlalchemy/issues/4481#issue-405370167
[2] https://gerrit.sqlalchemy.org/#/c/sqlalchemy/sqlalchemy/+/1184/
[3] https://github.com/sqlalchemy/sqlalchemy/issues/4538
diff -Nru sqlalchemy-1.2.18+ds1/debian/changelog 
sqlalchemy-1.2.18+ds1/debian/changelog
--- sqlalchemy-1.2.18+ds1/debian/changelog  2019-02-24 15:01:50.0 
-0800
+++ sqlalchemy-1.2.18+ds1/debian/changelog  2019-05-05 19:46:35.0 
-0700
@@ -1,3 +1,10 @@
+sqlalchemy (1.2.18+ds1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add upstream patch for CVE-2019-7164, CVE-2019-7548 
+
+ -- Ross Vandegrift   Sun, 05 May 2019 19:46:35 -0700
+
 sqlalchemy (1.2.18+ds1-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru sqlalchemy-1.2.18+ds1/debian/patches/0002-dla-1718-1.patch 
sqlalchemy-1.2.18+ds1/debian/patches/0002-dla-1718-1.patch
--- sqlalchemy-1.2.18+ds1/debian/patches/0002-dla-1718-1.patch  1969-12-31 
16:00:00.0 -0800
+++ sqlalchemy-1.2.18+ds1/debian/patches/0002-dla-1718-1.patch  2019-05-05 
19:45:46.0 -0700
@@ -0,0 +1,332 @@
+From 82b4dcdeb0505f2dfcece5f76045b28b0edda03d Mon Sep 17 00:00:00 2001
+From: Mike Bayer 
+Date: Mon, 08 Apr 2019 22:07:35 -0400
+Subject: [PATCH] Illustrate fix for #4481 in terms of a 1.2 patch
+
+Release 1.2 has decided (so far) not to backport 1.3's fix for #4481 as it is
+backwards-incompatible with code that relied upon the feature of automatic text
+coercion in SQL statements.  However, for the specific case of order_by() and
+group_by(), we present a patch that backports the specific change in compiler
+to have 1.3's behavior for order_by/group_by specifically.   This is much more
+targeted than the 0.9 version of the patch as it takes advantage 1.0's
+architecture which runs all order_by() / group_by() through a label lookup that
+only warns if the label can't be matched.
+
+For an example of an application that was actually impacted by 1.3's change
+and how they had to change it, see:
+
+https://github.com/ctxis/CAPE/commit/be0482294f5eb30026fe97a967ee5a768d032278
+
+Basically, in the uncommon case an application is actually using the text
+coercion feature which was generally little-known, within the order_by()
+and group_by() an error is now raised instead of a warning; the application
+must instead ensure the SQL fragment is passed within a text() construct.
+The above application has also been seeing a warning about this since 1.0
+which apparently remained unattended.
+
+The patch includes adjustments to the tests that were testing for the
+warning to now test that an exception is raised. Any distro that wants
+to patch the specific CVE issue resolved in #4481 to SQLAlchemy 1.0, 1.1
+or 1.2 can use this patch.
+
+Change-Id: I3363b21428f1ad8797394b63197375a2e56a0bd7
+References: #4481
+---
+
+diff --git a/lib/sqlalchemy/sql/compiler.py b/lib/sqlalchemy/sql/compiler.py
+index 5a11ed1..4780bab 100644
+--- a/lib/sqlalchemy/sql/compiler.py
 b/lib/sqlalchemy/sql/compiler.py
+@@ -757,12 +757,11 @@
+ else:
+ col = with_cols[element.element]
+ except KeyError:
+-# treat it like text()
+-util.warn_limited(
+-"Can't resolve label reference %r; converting to text()",
+-util.ellipses_string(element.element),
++elements._no_text_coercion(
++element.element,
++exc.CompileError,
++"Can't resolve label reference for ORDER BY / GROUP BY.",
+ )
+-return self.process(element._text_clause)
+ else:
+ kwargs["render_label_as_label"] = col
+ return self.process(
+diff --git a/lib/sqlalchemy/sql/elements.py b/lib/sqlalchemy/sql/elements.py
+index 299fcad..ff86deb 100644
+--- a/lib/sqlalchemy/sql/elements.py
 b/lib/sqlalchemy/sql/elements.py
+@@ -4432,6 +4432,17 @@
+ )
+ 
+ 
++def _no_text_coercion(element, exc_cls=exc.ArgumentError, extra=None):
++raise exc_cls(
++"%(extra)sTextual SQL expression %(expr)r should be "
++"explicitly declared as text(%(expr)r)"
++% {
++"expr": util.ellipses_string(element),
++"extra": "%s " % extra if extra else "",
++}
++)
++
++
+ def _no_literals(element):
+ if hasattr(element, "__clause_element__"):
+ return element.__clause_element__()
+diff --git a/test/orm/test_eager_relations.py 
b/test/orm/test_eager_relations.py
+index abcb597..fc9531d 100644
+---