Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions

From: Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions
Date: 2024-06-06 15:47:17
Message-ID: CAE9k0P=Aoo1FDGjRKPoRJiBMQq-yLRLTJSO6r5+ffoc+XqaeYA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

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.
>

I agree.

>
> * What exactly is the right search_path for a function defined in an
> extension?
>

Determining the precise value can be challenging. However, since it's a
function installed by an extension, typically, the search_path should
include the extension's search_path and the schema where the function
resides. If the function relies on a schema other than the one we set in
its search_path, which would usually be the one created by the extension,
this approach will enforce the extension developers to set the extension's
specific search_path in the create function statement, if it's not set. The
primary goal here is to ensure that the security definer functions created
by an extension do not refer to any untrusted schema(s).

>
> * 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?
>

Possibly yes, we can think about it, I think it would be something like the
$user we have now.

>
> * What do we do for functions that want the current behavior and how do
> we handle migration issues?
>

That can be controlled via some GUC if needed, I guess.

>
> * 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.
>

I didn't get you completely here. w.r.t extensions how will this have an
impact if we set the search_path for definer functions.

--
With Regards,
Ashutosh Sharma.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2024-06-06 15:57:21 Re: ResourceOwner refactoring
Previous Message Robert Haas 2024-06-06 15:33:43 Re: question regarding policy for patches to out-of-support branches