Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions

On Thu, Jun 6, 2024 at 2:36 AM Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
>
> On Wed, 2024-06-05 at 14:36 +0530, Ashutosh Sharma wrote:
> > Thank you, Ashutosh, for the quick response. I've drafted a patch
> > aimed at addressing this issue. The patch attempts to solve this
> > issue by configuring the search_path for all security definer
> > functions created by the extension.
>
> I like the general direction you propose, but I think it needs more
> discussion about the details.
>
> * What exactly is the right search_path for a function defined in an
> extension?
>
> * Do we need a new magic search_path value of "$extension_schema" that
> resolves to the extension's schema, so that it can handle ALTER
> EXTENSION ... SET SCHEMA?
>
> * What do we do for functions that want the current behavior and how do
> we handle migration issues?
>
> * What about SECURITY INVOKER functions? Those can still be vulnerable
> to manipulation by the caller by setting search_path, which can cause
> an incorrect value to be returned. That can matter in some contexts
> like a CHECK constraint.
>

Attached is the new version of patch addressing aforementioned
comments. It implements the following changes:

1) Extends the CREATE EXTENSION command to support a new option, SET
SEARCH_PATH.
2) If the SET SEARCH_PATH option is specified with the CREATE
EXTENSION command, the implicit search_path for functions created by
an extension is set, if not already configured. This is true for both
SECURITY DEFINER and SECURITY INVOKER functions.
3) When the ALTER EXTENSION SET SCHEMA command is executed and if the
function's search_path contains the old schema of the extension, it is
updated with the new schema.

Please have a look and let me know your comments.

--
With Regards,
Ashutosh Sharma.