Varonis Discovers New Vulnerability in PostgreSQL PL/Perl

Varonis’ researchers, Tal Peleg and Coby Abrams, discovered a vulnerability in the Postgres trusted language extension PL/Perl that allows setting arbitrary environment variables in PostgreSQL session processes.  

Depending on the scenario, this vulnerability can lead to severe security issues. In the official PostgreSQL report, the issue was given an 8.8 score for severity. 

PostgreSQL customers that use PL/Perl or have it available in their build of PostgreSQL are advised to upgrade their version of PostgreSQL. 

What is the impact on my organization?  

The vulnerability, named CVE-2024-10979 and given a score of 8.8, allows for modifying sensitive environment variables such as PATH, ultimately leading to the attacker executing arbitrary code with or without having access to an operating system user on the server. 

They can further run queries to gain additional information on the machine running the database and its contents. Our research team will share additional findings in an upcoming blog. 

What systems are affected? 

Incorrect control of environment variables in PostgreSQL PL/Perl allows an unprivileged database user to change sensitive process environment variables (e.g. PATH). Versions before PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21 are affected. 

How can I mitigate this vulnerability? 

Varonis recommends updating PostgreSQL to the latest minor version at a minimum, as well as restricting allowed extensions.  

For example, limiting CREATE EXTENSIONS permission grants to specific extensions and additionally setting the shared_preload_libraries configuration parameter to load only required extensions, limiting roles from creating functions per the principle of least privileges by restricting the CREATE FUNCTION permission. 

To test whether you are using functions that access or modify environment variables, look for references to the ENV hash in your function code. 

	
		
SELECT 
proname, 
prosrc 
FROM 
pg_proc 
WHERE 
prolang = (SELECT oid FROM pg_language WHERE lanname = 'plperl') 
AND prosrc LIKE '%$ENV{%'; 
	

Additionally, Postgres customers should look at ddl logs for creation of plperl functions they do not recognize. 

See the full description of the fix, as well as advanced remediation options, in this commit from the Postgres team, summarized here: 

To fix PL/Perl, replace trusted PL/Perl %ENV with a tied hash that just replaces each modification attempt with a warning. Sites that reach these warnings should evaluate the application-specific implications of proceeding without the environment modification: 

Can the application reasonably proceed without the modification? 

If no, switch to plperlu or another approach. 

If yes, the application should change the code to stop attempting environment modifications. If that's too difficult, add "untie %main::ENV" in any code executed before the warning. For example, one might add it to the start of the affected function or even to the plperl.on_plperl_init setting. 

In passing, link to Perl's guidance about the Perl features behind the security posture of PL/Perl. 

Back-patch to v12 (all supported versions). 

Need additional help? 

For additional assistance, please contact our team.