Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions

On Wed, Jun 12, 2024 at 2:05 PM John H <johnhyvr(at)gmail(dot)com> wrote:>
> I'm sympathetic to the problem of potential privilege escalation when
> executing functions. At the same time I'm not sure if there's that
> much of a difference between 'CREATE EXTENSION' vs superusers copying
> a series of 'CREATE FUNCTION' where they don't understand these same
> nuances.

+1.

> CREATE FUNCTION already provides an ability to set the search_path. So
> I'm wondering what the problem we want to solve here is. Is it that
> there's too much friction for extension authors to have to set
> search_path as part of the function definition and we want to make it
> easier for them to "set once and forget"?

If that's the problem we want to solve, I'm unconvinced that it's
worth doing anything. But I think there's another problem, which is
that if the extension is relocatable, how do you set a secure
search_path? You could say SET search_path = foo, pg_catalog if you
know the extension will be installed in schema foo, but if you don't
know in what schema the extension will be installed, then what are you
supposed to do? The proposal of litting $extension_schema could help
with that ...

...except I'm not sure that's really a full solution either, because
what if the extension is installed into a schema that's writable by
others, like public? If $extension_schema resolves to public and
public allows CREATE access to normal users, you're in a lot of
trouble again already, because now an attacker can try to capture
operator references within your function, or function calls that are
approximate matches to some existing function by introducing perfect
matches that take priority. Perhaps we want to consider the case where
the attacker can write to the schema containing the extension as an
unsupported scenario, but if so, we'd better be explicit about that.

--
Robert Haas
EDB: http://www.enterprisedb.com