MySQL UDF提权漏洞原理与防范方法

相比单纯删除函数，禁用 CREATE FUNCTION 权限更关键。原因在于，只要这个权限仍然存在，攻击者就可以随时重新注册新的 UDF，并上传恶意 .so 文件；而删除函数只是清理现有记录，无法从根源上阻止其再次创建。

为什么禁用 CREATE FUNCTION 权限比删函数更重要

很多人在谈到 MySQL UDF 提权漏洞时，第一步往往是检查 mysql.func 表，然后删除 sys_eval 或 lib_mysqludf_sys.so 等可疑项。但这样做更像是清除了表面痕迹，并没有真正切断风险来源。只要攻击者仍然拥有执行 CREATE FUNCTION 的权限，就可以立即重新注册恶意函数；如果文件系统依旧可写，恶意 .so 动态库也能被再次上传并利用。

真正有效的防护重点在于权限控制：

• CREATE FUNCTION 是注册 UDF 的前置条件，必须从所有业务账号中完全收回
• 检查命令：SHOW GRANTS FOR 'app_user'@'%';，重点确认是否包含 CREATE ROUTINE（它会隐含 CREATE FUNCTION）
• 回收权限时必须执行：REVOKE CREATE ROUTINE ON *.* FROM 'app_user'@'%';（注意不能写成 ON mydb.*）
• 即便应用账号只是只读场景，也不能授予 EXECUTE 权限——因为它允许调用已经存在的 UDF

secure_file_priv 不是摆设，但配置错等于没设

@@secure_file_priv 用于限制 SELECT ... INTO OUTFILE 与 LOAD DATA INFILE 的文件读写路径。它并不是简单的“启用/禁用”开关，而更像是一道目录边界。如果配置不当，不但起不到防护作用，反而容易造成错误的安全判断。

常见错误配置及修复方法：

• 值为 NULL 或空字符串：虽然 MySQL 8.0+ 已禁止这种设置，但在旧版本中依然可能存在，必须在 my.cnf 中显式指定有效目录（如 /var/lib/mysql-files/）并重启服务
• 设为 / 或 /tmp：攻击者可以直接写入类似 /tmp/lib_pwn.so 的恶意文件，再通过符号链接绕过插件目录限制（MySQL 8.0.29+ 已禁用符号链接，但旧版本仍需手动排查）
• 正确做法：将其设置为仅允许 mysql 用户写入的空目录（如 /var/lib/mysql-udf-block/），然后执行 chown mysql:mysql /var/lib/mysql-udf-block && chmod 700 /var/lib/mysql-udf-block
• 验证命令：SELECT @@secure_file_priv; 和 SELECT @@plugin_dir; 必须分别检查，确保两个路径既不重叠，也不存在可交叉写入的风险

UDF 文件本身要清理，但得按规则删

MySQL UDF 提权通常依赖两个关键对象：一是数据库中的注册记录（mysql.func 表），二是磁盘上的共享库文件（如 .so 或 .dll）。如果只删除表记录而不清理文件，后续仍可通过 CREATE FUNCTION 直接复用；如果只删除文件而不清空注册项，MySQL 启动时虽然通常不会崩溃，但会产生报错，同时攻击者仍有机会重新上传恶意文件。

因此，清理流程必须形成闭环：

• 先检查注册项：SELECT name, dl FROM mysql.func;，对每条结果执行 DROP FUNCTION IF EXISTS `name`;
• 再定位文件：find /var/lib/mysql* -name "*.so" -o -name "lib_mysqludf_*" 2>/dev/null，逐一执行 rm -f 删除
• 检查插件目录权限：ls -ld $(mysql -Nse "SELECT @@plugin_dir")，确认属主为 mysql，权限不高于 755（写权限仅保留给 mysql 用户）
• 重启 mysqld 后，再次执行 SELECT name FROM mysql.func;，确认结果为空

应用层 SQL 注入才是真正的入口，配置加固只是延缓器

归根结底，大多数 MySQL UDF 提权漏洞的起点，并不是 DBA 忽略了某项配置，而是 Web 应用存在 SQL 注入风险，把用户输入直接拼接进了 SQL 语句。即使 secure_file_priv 配置得很严格，CREATE FUNCTION 权限也被收得很彻底，只要代码里还保留类似 WHERE id = " . $_GET['id'] 这样的拼接方式，攻击者仍然可以借此入侵：通过 UNION SELECT 写文件、利用报错注入窃取敏感数据，甚至进一步拿到 shell。

修补这一入口没有捷径：

• PHP 必须使用 PDO::prepare() + bindValue()，禁用 mysql_query() 和 mysqli_query() 直接拼接 SQL
• Python 应使用 cursor.execute("SELECT * FROM users WHERE id = %s", [user_id])，拒绝任何形式的 f-string 或 .format() 拼接 SQL
• Ja va 使用 PreparedStatement，严禁 Statement.execute(sql + input)
• 在 ORM 框架中禁用高风险原生 SQL 接口：例如 Django 的 extra()、SQLAlchemy 的 text() 如果包含变量拼接，应一律视为高危操作

还有一个最容易被忽视的问题：很多开发者以为“用了 ORM 就天然安全”，但在日志埋点、动态排序字段、IN 查询拼装等场景中，又重新回到了字符串拼接。恰恰这些细节位置，往往才是 MySQL UDF 提权攻击最常利用的突破口。