CVE-2024-10979: Unprivileged Database User Gains Control of Sensitive Environment Variables in PostgreSQL PL/Perl, Enabling Arbitrary Code Execution

---

Introduction

A critical vulnerability, CVE-2024-10979, has been discovered in several versions of PostgreSQL before 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21. This security issue allows an unprivileged database user to modify sensitive process environment variables, such as the PATH, within PostgreSQL PL/Perl. In many cases, this level of access can enable arbitrary code execution, even if the attacker does not have a PostgreSQL server operating system user.

In this long-read post, we'll dive into the details of this vulnerability, explore a code snippet that demonstrates the exploit, provide links to related references, and discuss how to prevent and mitigate the issue.

Vulnerability Details

The vulnerability arises from improper control of environment variables in PostgreSQL's PL/Perl, a procedural language extension that allows users to create user-defined functions written in Perl. An unprivileged database user can exploit this issue by altering critical environment variables, such as the PATH, which can lead to arbitrary code execution.

The following code snippet demonstrates how an attacker could exploit this vulnerability

# Database user code
CREATE OR REPLACE FUNCTION malicious_function()
RETURNS VOID AS $$
  BEGIN
    # Modify the environment variable 'PATH'
    $ENV{'PATH'} = '/path/to/malicious/directory:' . $ENV{'PATH'};
  END;
$$ LANGUAGE plperl;

In this snippet, a database user creates a new function called 'malicious_function'. When executed, the function modifies the environment variable 'PATH' to include a malicious directory. With control over the PATH, the attacker can execute arbitrary code by getting the PostgreSQL server to run a command that exists in the attacker-controlled directory.

Once an attacker gains control over the PATH, they have several ways to exploit this vulnerability

1. Create a malicious executable or script with the same name as a commonly-used command in the user-defined function, such as 'ls,' 'grep,' or 'ps'. If the PostgreSQL server attempts to execute this command, the attacker's version will run instead.

2. Take advantage of any system or user-defined functions in the server that execute shell commands or spawn subprocesses. If any of these functions use a command in the attacker-controlled PATH, the attacker can execute arbitrary code.

3. If the attacker can predict when the server will execute a shell command (e.g., during a specific maintenance task), they can temporarily modify the PATH to include their malicious directory at the right time.

To exploit any of these scenarios, an attacker does not need a PostgreSQL server operating system user, making this vulnerability even more dangerous.

Original References

- CVE-2024-10979 Official CVE Information: Link
- PostgreSQL Security Announcement: Link
- PostgreSQL Release Notes: Link

Preventing and Mitigating the Issue

To prevent attackers from exploiting this vulnerability, it's crucial to update PostgreSQL to a version not affected by this issue. The patch is available in PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, and 12.21. Upgrading to one of these versions will remove the vulnerability and protect your PostgreSQL installation from unauthorized environment variable changes.

If upgrading is not possible, the following steps can be taken to mitigate the risk

1. Limit access to PL/Perl functions only to trusted users.
2. Restrict PL/Perl usage to specific database schemas using schema-based access controls.
3. Monitor the execution of commands spawned by PostgreSQL and detect any deviations from expected command execution patterns.

By implementing these measures, you can reduce the likelihood of unauthorized environment variable changes and decrease the risk of arbitrary code execution.

Conclusion

CVE-2024-10979 is a serious vulnerability that allows an unprivileged database user to modify sensitive environment variables within PostgreSQL PL/Perl. Exploiting this issue often enables arbitrary code execution even without a PostgreSQL server operating system user. It's crucial to update your PostgreSQL installation to a patched version or implement the suggested mitigation steps to protect your database server from potential attacks.

Timeline

Published on: 11/14/2024 13:15:04 UTC