Hi,
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
.
Here is a simple test case to reproduce the problem.
Create the following two functions in, say, postgres database.
CREATE FUNCTION public.evil_eq(oid, integer) RETURNS boolean
LANGUAGE plpgsql
AS $$
begin
raise warning 'trojan';
return oideq($1, $2::oid);
end
$$;
CREATE OPERATOR public.= (
PROCEDURE = public.evil_eq,
LEFTARG = oid,
RIGHTARG = integer
);
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
.........
..........
<< the above is repated 439 times>>
<pgdb.Cursor object at 0x7fe91665c650>
>>>
Running another query such as 'SELECT * FROM pg_catalog.pg_class LIMIT 1'
calls the public.evil_eq() function more than two thousand times.
Also, this happens when the first time you run the query after creating the
function and connecting. Therefore, the call to OPERATOR(=) is done by
PyGreSQL internal queries to get metadata information from the server after
initial connect.
The Wiki
https://wiki.postgresql.org/wiki/A_Guide_to_CVE-2018-1058:_Protect_Your_Search_Path
provided instructions for DBAs to mitigate the impact of the vulnerability.
Essentially asking that references to the database objects and operators
should be fully schema-qualified to prevent an override from a less
privileged user.
Therefore, I was wondering if the PyGreSQL community has any plans to fully
schema-qualify objects and operators for all the internal queries that
PyGreSQL issues?
Thank you.
Shoaib
_______________________________________________
PyGreSQL mailing list
[email protected]
https://mail.vex.net/mailman/listinfo/pygresql
