glibc漏洞使数百万Linux系统面临代码执行风险

GNU C 库(glibc)中新报告的漏洞,是无数 Linux 应用程序的基本组成部分,它详细介绍了静态 setuid 二进制文件的共享库加载机制中可能可利用的弱点。

跟踪为 CVE-2025-4802,environment该漏洞源于静态 setuid 二进制文件在通过 dlopen() 进行动态库调用时不正确使用 LD_LIBRARY_PATH 环境变量。

GNU C 库或 glibc 是 GNU 工程和几乎所有主要 Linux 发行版所使用的标准 C 库。它充当操作系统内核和用户空间程序之间的桥梁,实现输入/输出处理、内存分配和网络通信等基本功能。

虽然glibc主要用于动态链接的二进制文件,但它也支持静态链接的可执行文件 – 自包含的程序,包括编译时所有必要的库。

缺陷在于静态 setuid 二进制文件与动态加载器之间的相互作用。advisory根据咨询:

调用 dlopen(包括 setlocale 后的内部 dlopen 调用或调用 NSS 函数(如 getaddrinfo)的静态链接 setuid 二进制文件可能会错误地搜索 LD_LIBRARY_PATH 以确定要加载的库,从而导致执行由攻击者控制的库代码。

通常,像LD_LIBRARY_PATH这样的环境变量被特权二进制文件(即那些有setuid的二进制文件)忽略,以避免引入安全风险。然而,CVE-2025-4802打破了这一假设,允许恶意用户在存在易受攻击的setuid二进制文件并直接或通过常见的libc依赖函数调用dlopen()时注入任意代码。

风险被归类为局部和情境,因为它需要:

系统上的静态链接 setuid 二进制文件。

二进制文件必须调用 dlopen()()——手动或通过间接 libc/NSS 调用。

environment环境必须允许用户设置 LD_LIBRARY_PATH。

该咨询机构承认:“在发布此咨询时没有发现此类计划,但定制setuid程序的存在,尽管作为安全实践受到强烈劝阻,但不能打折扣。

这使得该漏洞成为低概率但高影响力的漏洞,特别是在具有遗留或自定义静态二进制文件的环境中。

系统管理员和 Linux 发行商应:

将 glibc 更新到 2.39 版本,或者如果维护自定义构建,请手动应用修复程序。

审核静态 setuid 二进制文件,并在可能的情况下删除或重新编译它们与动态链接。