Уязвимость некорректного применения политик безопасности строк в PostgreSQL при изменении идентификатора пользователя после инлайнинга
Описание
В PostgreSQL политики безопасности строк не учитывают изменения идентификатора пользователя после инлайнинга, что позволяет некорректным политикам применяться в определённых случаях. Это происходит, если используются политики, зависящие от роли, и запрос планируется под одной ролью, а выполняется под другой. Такой сценарий возможен в функциях, определённых для безопасного выполнения, или когда общий пользователь и запрос изначально планируются и затем повторно используются через несколько SET ROLE. Применение некорректной политики может позволить пользователю выполнить чтение и модификации данных, которые в обычном случае запрещены. Это затрагивает только базы данных, в которых определена политика безопасности строк с помощью CREATE POLICY.
Тип уязвимости
Некорректное применение политик безопасности
Ссылки
- Third Party Advisory
- Vendor Advisory
- Third Party Advisory
- Vendor Advisory
Уязвимые конфигурации
Одно из
Одно из
EPSS
5.4 Medium
CVSS3
Дефекты
Связанные уязвимости
Row security policies disregard user ID changes after inlining; PostgreSQL could permit incorrect policies to be applied in certain cases where role-specific policies are used and a given query is planned under one role and then executed under other roles. This scenario can happen under security definer functions or when a common user and query is planned initially and then re-used across multiple SET ROLEs. Applying an incorrect policy may permit a user to complete otherwise-forbidden reads and modifications. This affects only databases that have used CREATE POLICY to define a row security policy.
Row security policies disregard user ID changes after inlining; PostgreSQL could permit incorrect policies to be applied in certain cases where role-specific policies are used and a given query is planned under one role and then executed under other roles. This scenario can happen under security definer functions or when a common user and query is planned initially and then re-used across multiple SET ROLEs. Applying an incorrect policy may permit a user to complete otherwise-forbidden reads and modifications. This affects only databases that have used CREATE POLICY to define a row security policy.
Row security policies disregard user ID changes after inlining; Postgr ...
Row security policies disregard user ID changes after inlining; PostgreSQL could permit incorrect policies to be applied in certain cases where role-specific policies are used and a given query is planned under one role and then executed under other roles. This scenario can happen under security definer functions or when a common user and query is planned initially and then re-used across multiple SET ROLEs. Applying an incorrect policy may permit a user to complete otherwise-forbidden reads and modifications. This affects only databases that have used CREATE POLICY to define a row security policy.
EPSS
5.4 Medium
CVSS3