PostgreSQL Anonymizer vulnerabilities

PostgreSQL Anonymizer before 3.3.0 leaves statistics about the original data visible in pg_stats until an ANALYZE operation is performed on the table, either manually or by autovacuum. This can expose information about masked data.

The anon.partial() and anon.partial_email() functions in PostgreSQL Anonymizer before 3.3.0 can reveal the whole data if the data is small enough. The issue is fixed in version 3.3.0.

PostgreSQL Anonymizer before 3.3.0 mishandles anonymization functions defined using SQL-standard function bodies. PostgreSQL analyzes such functions at declaration time while Anonymizer only checks them at execution time, which can be exploited by any user with the TEMPORARY privilege.

PostgreSQL Anonymizer before 3.3.0 does not mask data returned by a sub-query in a rule. The problem is resolved in version 3.3.0.

PostgreSQL Anonymizer before 3.3.0 does not mask data accessed through a security_invoker view. The problem is resolved in version 3.3.0.

PostgreSQL Anonymizer's documentation recommends applying rules on partitions and inheritance tables, but direct access to partitions is masked while access through the parent table is not. The problem is resolved in version 3.3.0.

PostgreSQL Anonymizer before 3.3.0 does not invalidate plans prepared after a rule was added or a role changed. Users using such plans can still see unmasked data until the end of the session.

PostgreSQL restricts access to the salt and shift via the SHOW command for users not in pg_read_all_settings, but they are visible in pg_db_role_setting or pg_roles if set on the database, user, or both. PostgreSQL Anonymizer's documentation recommends using ALTER DATABASE / ALTER ROLE for the salt; the problem is resolved in version 3.3.0.

PostgreSQL's optimized statistics on a table are visible to anyone with SELECT privilege on that table. A masked role can therefore read a limited subset of data through the statistics view's histograms and MCVs.

The anon.image_blur() function in PostgreSQL Anonymizer before 3.3.0 does not check the declared dimensions of the provided image, allowing an attacker to supply a small image with enormous declared dimensions. This can exhaust backend memory and cause an OOM-kill, resulting in cluster-wide crash recovery.

PostgreSQL Anonymizer's range-based dummy functions do not constrain the range size. This can be exploited to exhaust backend memory and OOM-kill it (when overcommit is on), resulting in cluster-wide crash recovery.

PostgreSQL Anonymizer contains a vulnerability where data-modifying CTEs bypass the read-only restriction of masked roles. The problem is resolved in version 3.3.0 and later.

PostgreSQL Anonymizer contains a vulnerability that allows unprivileged masked users to repeatedly call anon.hash() and collect (seed, hash_output) pairs to perform an offline brute-force attack and deduce the salt. The issue is fixed in version 3.2.3.

PostgreSQL Anonymizer contains a vulnerability in the anon.anonymize_database_parallel() function that allows a table owner to execute arbitrary code with superuser privileges. The issue is fixed in version 3.2.0 and later.

PostgreSQL Anonymizer contains a SQL injection vulnerability in two import functions. A user can create a malicious JSON document with specially crafted object names. If a superuser calls anon.import_database_rules() or anon.import_roles_rules(), malicious code is executed with superuser privileges. Fixed in version 3.1.4 and later.

PostgreSQL Anonymizer contains a vulnerability allowing unprivileged masked users to execute arbitrary code by abusing operators, domain casts, or view subqueries carrying untrusted expressions. When evaluated in the masking context, malicious code can run with elevated privileges. Fixed in version 3.1.4 and later.

A vulnerability in PostgreSQL Anonymizer allows unprivileged masked users to repeatedly call the anon.hash() function and collect (seed, hash_output) pairs to perform an offline brute-force attack and deduce the salt.

PostgreSQL Anonymizer contains a vulnerability that allows a user to gain superuser privileges by creating a JSON document and placing malicious code inside a particular key-value pair. If a superuser calls the import_database_rules() or import_roles_rules() functions, the malicious code is executed with superuser privileges.