From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Bug - DoS - Handler function lookups consider non-handler functions |
Date: | 2025-03-22 17:07:55 |
Message-ID: | CAKFQuwYBTcK+uW-BYFChHP8HYj0R5+UpytGmdqEvP9PHCSZ+-g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Today:
create extension tsm_system_rows ;
create schema s1;
create function s1.system_rows(internal) returns void language c as
'tsm_system_rows.so', 'tsm_system_rows_handler';
set search_path to s1,public,pg_catalog;
select count(*) from pg_class tablesample system_rows(0);
ERROR: function system_rows must return type tsm_handler
LINE 1: select count(*) from pg_class tablesample system_rows(0);
The above is a denial-of-service due to our decision to lookup handler
functions by name regardless of return type and consider it an error if a
function with the wrong return type shows up (in particular, even though
one with the correct signature exists and otherwise would have been found).
The attached POC fixes this by allowing callers to also specify the OID of
the handler type as part of their function lookup criteria. Tablesample is
fixed to use this new call though possibly others exist. I'm not
particularly fond of what I ended up with naming conventions but figure
it's good enough for now.
Patch applied and re-running the above:
select count(*) from pg_class tablesample system_rows(0);
count
-------
0
(1 row)
I noticed this when reviewing the extensible copy formats patch which used
tablesample as a reference.
David J.
Attachment | Content-Type | Size |
---|---|---|
v0-0001-Handler-function-lookups-ignore-non-handler-function.patch | application/x-patch | 10.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2025-03-22 17:11:10 | Re: Make COPY format extendable: Extract COPY TO format implementations |
Previous Message | Jeff Davis | 2025-03-22 16:39:30 | Re: Reduce TupleHashEntryData struct size by half |