Am 16.08.2019 um 19:58 schrieb Shoaib Lari:
> I was wondering if the PyGreSQL community has any plans to address
> PostgreSQL security vulnerability
>
https://wiki.postgresql.org/wiki/A_Guide_to_CVE-2018-1058:_Protect_Your_Search_Path.
Hi Shoaib, thanks for bringing this to our attention.
> Now connect to the postgres database thorough pygresql, and issue a
> simple query.
>
> import pgdb
> conn = pgdb.connect(database='postgres')
> c = conn.cursor()
> c.execute('SELECT 1')
>
> You will get the following output:
>
> WARNING: trojan
So what's happening here is that the equality operator used in the
internal query used by the type cache is called which triggers the
warning above because you have overridden the operator in the public
schema which takes precedence before the default one in pg_catalog.
Now, if someone was able to do that I think your goose has been cooked
anyway since nearly every query will be affected.
The internal query used by the type cache looks something like this:
SELECT oid, typname, ... FROM pg_type WHERE oid=%s
As far as I understand, to make things secure at least what concerns
PyGreSQL, we would need to change that query to:
SELECT oid, typname, ... FROM pg_catalog.pg_type
WHERE oid OPERATOR(pg.catalog.=) %s
And there's another query for composite types that needs to be fixed in
a similar way. We would also need to fix the internal query in the
classic pg.py module, which has not only a type cache but also other
higher level functions which run internal queries.
This would make the queries look more ugly and lengthy. Not sure about
the performance impact - maybe it would be even faster because of the
explicit schema name.
What do others think? Should we make these changes?
The guide that you linked to says this:
"If you write your queries with specific schema.object form, including
objects that exist in the pg_catalog (e.g. calling SELECT
pg_catalog.lower('ALICE');), then you are not immediately vulnerable to
this issue."
But it does not mention operators in this context which are easily
overlooked and which will make any query secured that way immediately
become very ugly. In practice I think that's not feasible except when
all queries are created automatically e.g. by an ORM.
I think in practice you need to rely on users not being able to create
objects in the public schema, otherwise you're set for deeper troubles
anyway, no matter how secure your API is.
-- Christoph
_______________________________________________
PyGreSQL mailing list
PyGreSQL@Vex.Net
https://mail.vex.net/mailman/listinfo/pygresql
