On Sat, Aug 24, 2019 at 10:05:46PM +0200, Christoph Zwerschke wrote: > 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.
Yes, thanks for mentioning it. > 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 Yes, I think > 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. I agree that they're uglier... > What do others think? Should we make these changes? But I tend to think we should add schema quals, since that's what postgres does. See the commit for that CVE: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=3d2aed664ee8271fd6c721ed0aa10168cda112ea;hp=3bf05e096b9f8375e640c5d7996aa57efd7f240c But it looks like that convention dates back to: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=039cb479884abc28ee494f6cf6c5e7ec26b88fc8 See describe.c https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/bin/psql/describe.c For example \d makes a half dozen queries which look like: [pryzbyj@database ~]$ psql ts -Ec '\d pg_class' ********* QUERY ********** SELECT c.oid, n.nspname, c.relname FROM pg_catalog.pg_class c LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace WHERE c.relname OPERATOR(pg_catalog.~) '^(pg_class)$' AND pg_catalog.pg_table_is_visible(c.oid) ORDER BY 2, 3; ************************** > Now, if someone was able to do that I think your goose has been cooked > anyway since nearly every query will be affected. ... > 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. | Without adjusting the configuration or access control settings, any user that can connect to a database can also create objects in the public schema for that database. It's true that one shouldn't create untrusted DB users, but there's a privilege system in place and it's intended to allow users to be at least partially segregated. If postgres/pygres and other projects don't use schema quals, then it's hard to imagine that a typical admin will do so. _______________________________________________ PyGreSQL mailing list PyGreSQL@Vex.Net https://mail.vex.net/mailman/listinfo/pygresql
