Cybersecurity researchers Tal Peleg and Coby Abrams from Varonis have unveiled a significant security vulnerability within the popular open-source database system, PostgreSQL. This vulnerability, designated as CVE-2024-10979, poses a serious risk to the integrity of databases globally.
As detailed in Varonis’ report, which was shared with Hackread.com prior to its official release, the vulnerability has been assigned a troubling score of 8.8 on the CVSS severity scale. This alarming rating underscores the critical nature of the flaw, affecting all PostgreSQL versions prior to 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21.
The vulnerability allows unprivileged users to manipulate environment variables within the PostgreSQL PL/Perl extension. This extension facilitates the creation of database functions using the Perl programming language. An attacker could exploit this weakness to alter environment variables on the server hosting the database.
According to PostgreSQL’s advisory, “Incorrect control of environment variables in PostgreSQL PL/Perl allows an unprivileged database user to change sensitive process environment variables (e.g., PATH). That often suffices to enable arbitrary code execution, even if the attacker lacks a database server operating system user.”
Environment variables function as concealed settings that dictate program behavior. By modifying these variables, an attacker could potentially execute malicious code, leading to data theft or system takeover. Additionally, these variables may contain sensitive information such as access keys or file paths, making them prime targets for exploitation.
To mitigate this vulnerability, immediate action is required. Users are advised to update their PostgreSQL installations to versions 17.1, 16.5, 15.9, 14.14, 13.17, or 12.21, all of which include the necessary fixes. Varonis further recommends updating PostgreSQL to the latest minor version and implementing restrictions on allowed extensions. This includes limiting the permissions for creating extensions to specific ones and configuring the shared_preload_libraries parameter to load only essential libraries. A comprehensive description of the fix can be found here.
Moreover, it is advisable to restrict the extensions that users can install within the database to thwart potential exploitation of vulnerabilities, while also ensuring that users are granted the least privileges necessary to minimize potential damage.