public inbox for [email protected]  

help / color / mirror / Atom feed

From: Ashutosh Sharma <[email protected]>
To: pgsql-hackers <[email protected]>
Subject: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions
Date: Fri, 24 May 2024 12:51:43 +0530
Message-ID: <CAE9k0PkYvF2RSbHeBL4UyROABAGYMwD0_HTZ3rp_o=OUvWpXiw@mail.gmail.com> (raw)

Hi All,

We all know that installing an extension typically requires superuser
privileges, which means the database objects it creates are owned by the
superuser.

If the extension creates any SECURITY DEFINER functions, it can introduce
security vulnerabilities. For example, consider an extension that creates
the following functions, outer_func and inner_func, in the schema s1 when
installed:

CREATE OR REPLACE FUNCTION s1.inner_func(data text)
RETURNS void AS $$
BEGIN
    INSERT INTO tab1(data_column) VALUES (data);
END;
$$ LANGUAGE plpgsql;

CREATE OR REPLACE FUNCTION s1.outer_func(data text)
RETURNS void AS $$
BEGIN
    PERFORM inner_func(data);
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;

If a regular user creates another function with name "inner_func" with the
same signature in the public schema and sets the search path to public, s1,
the function created by the regular user in the public schema takes
precedence when outer_func is called. Since outer_func is marked as
SECURITY DEFINER, the inner_func created by the user in the public schema
is executed with superuser privileges. This allows the execution of any
statements within the function block, leading to potential security issues.

To address this problem, one potential solution is to adjust the function
resolution logic. For instance, if the caller function belongs to a
specific schema, functions in the same schema should be given preference.
Although I haven’t reviewed the feasibility in the code, this is one
possible approach.

Another solution could be to categorize extension-created functions to
avoid duplication. This might not be an ideal solution, but it's another
consideration worth sharing.

Thoughts?

--
With Regards,
Ashutosh Sharma.

view thread (2+ messages)

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected]
  Subject: Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions
  In-Reply-To: <CAE9k0PkYvF2RSbHeBL4UyROABAGYMwD0_HTZ3rp_o=OUvWpXiw@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox