Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions

On Fri, May 24, 2024 at 2:25 PM Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
wrote:

>
>
> On Fri, May 24, 2024 at 12:52 PM Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>
> wrote:
>
>> 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.
>>
>>
> Function call should schema qualify it. That's painful, but it can be
> avoided by setting a search path from inside the function. There was some
> discussion about setting a search path for a function at [1]. But the last
> message there is non-conclusive. We may want to extend it to extensions
> such that all the object references in a given extension are resolved using
> extension specific search_path.
>
> [1]
> https://www.postgresql.org/message-id/2710f56add351a1ed553efb677408e51b060e67c.camel%40j-davis.com
>

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. It ensures they are set to trusted schemas, which includes
the schema where the extension and the function are created. PFA patch.

--
With Regards,
Ashutosh Sharma.