Podatności PostgreSQL Anonymizer

PostgreSQL Anonymizer w wersjach przed 3.3.0 pozostawia statystyki dotyczące oryginalnych danych widoczne w pg_stats do momentu wykonania ANALYZE na tabeli (ręcznie lub przez autovacuum). Może to ujawnić informacje o zamaskowanych danych.

Funkcje anon.partial() i anon.partial_email() w PostgreSQL Anonymizer przed wersją 3.3.0 mogą ujawnić całe dane, jeśli są one wystarczająco krótkie. Problem został naprawiony w wersji 3.3.0.

PostgreSQL Anonymizer przed wersją 3.3.0 nieprawidłowo obsługuje funkcje anonimizujące zdefiniowane za pomocą ciał funkcji w standardzie SQL. PostgreSQL analizuje takie funkcje w momencie deklaracji, podczas gdy Anonymizer sprawdza je dopiero przy wykonaniu, co może wykorzystać każdy użytkownik z uprawnieniem TEMPORARY.

PostgreSQL Anonymizer przed wersją 3.3.0 nie maskuje danych zwracanych przez podzapytanie w regule. Problem został rozwiązany w wersji 3.3.0.

PostgreSQL Anonymizer przed wersją 3.3.0 nie maskuje danych dostępnych przez widok z opcją security_invoker. Problem został rozwiązany w wersji 3.3.0.

Dokumentacja PostgreSQL Anonymizer zaleca stosowanie reguł na partycjach i tabelach dziedziczących, jednak bezpośredni dostęp do partycji jest maskowany, a dostęp przez tabelę nadrzędną już nie. Problem został rozwiązany w wersji 3.3.0.

PostgreSQL Anonymizer przed wersją 3.3.0 nie unieważnia planów przygotowanych po dodaniu reguły lub zmianie roli. Użytkownicy korzystający z takich planów mogą nadal widzieć niezamaskowane dane do końca sesji.

PostgreSQL ogranicza dostęp do salt i shift przez polecenie SHOW dla użytkowników spoza pg_read_all_settings, ale wartości te są widoczne w pg_db_role_setting lub pg_roles, jeśli ustawiono je na poziomie bazy danych, użytkownika lub obu. Dokumentacja PostgreSQL Anonymizer zaleca używanie ALTER DATABASE / ALTER ROLE dla salt; problem rozwiązano w wersji 3.3.0.

Zoptymalizowane statystyki tabeli w PostgreSQL są widoczne dla każdego, kto ma uprawnienie SELECT na tej tabeli. Zamaskowana rola może więc odczytać ograniczony podzbiór danych poprzez histogramy i MCV w widoku statystyk.

Funkcja anon.image_blur() w PostgreSQL Anonymizer przed wersją 3.3.0 nie sprawdza zadeklarowanych wymiarów dostarczonego obrazu, co pozwala atakującemu podać mały obraz z ogromnymi zadeklarowanymi wymiarami. Może to wyczerpać pamięć backendu i doprowadzić do OOM-kill oraz odzyskiwania klastra po awarii.

Funkcje generujące dane zastępcze oparte na zakresach w PostgreSQL Anonymizer nie ograniczają rozmiaru zakresu. Można to wykorzystać do wyczerpania pamięci procesu backendu i jego zabicia przez OOM killer (przy włączonym overcommit), co prowadzi do awaryjnego odzyskiwania całego klastra.

PostgreSQL Anonymizer zawiera podatność pozwalającą obejść ograniczenie tylko-do-odczytu ról zamaskowanych za pomocą CTE modyfikujących dane. Problem został rozwiązany w wersji 3.3.0 i nowszych.

Podatność w PostgreSQL Anonymizer pozwala nieuprzywilejowanym użytkownikom z rolą maskującą wielokrotnie wywoływać funkcję anon.hash() i zbierać pary (seed, hash_output) w celu przeprowadzenia ataku brute-force offline i odgadnięcia soli. Problem rozwiązano w wersji 3.2.3.

PostgreSQL Anonymizer zawiera podatność w funkcji anon.anonymize_database_parallel(), która pozwala właścicielowi tabeli na wykonanie dowolnego kodu z uprawnieniami superużytkownika. Problem został naprawiony w wersji 3.2.0 i późniejszych.

PostgreSQL Anonymizer zawiera podatność na wstrzyknięcie SQL w dwóch funkcjach importujących. Użytkownik może utworzyć złośliwy dokument JSON z odpowiednio spreparowanymi nazwami obiektów. Jeśli superużytkownik wywoła anon.import_database_rules() lub anon.import_roles_rules(), złośliwy kod zostanie wykonany z uprawnieniami superużytkownika. Problem naprawiono w wersji 3.1.4 i późniejszych.

PostgreSQL Anonymizer zawiera podatność umożliwiającą nieuprzywilejowanym zamaskowanym użytkownikom wykonanie dowolnego kodu poprzez nadużycie operatorów, rzutowań domen lub podzapytań widoków zawierających niezaufane wyrażenia. Gdy te obiekty są oceniane w kontekście mechanizmów maskowania rozszerzenia, złośliwy kod może zostać wykonany z podwyższonymi uprawnieniami. Problem naprawiono w wersji 3.1.4 i późniejszych.

Podatność w PostgreSQL Anonymizer pozwala nieuprzywilejowanym użytkownikom na wielokrotne wywoływanie funkcji anon.hash() i zbieranie par (seed, hash_output) w celu przeprowadzenia ataku brute-force offline i odgadnięcia soli.

PostgreSQL Anonymizer zawiera podatność, która pozwala użytkownikowi uzyskać uprawnienia superużytkownika poprzez stworzenie dokumentu JSON z złośliwym kodem w określonej parze klucz-wartość. Jeśli superużytkownik wywoła funkcje import_database_rules() lub import_roles_rules(), złośliwy kod zostanie wykonany z uprawnieniami superużytkownika.