绝命中的一助linux程序加载器ld-linux.so中的LD_PRELOAD预加载库

最新推荐文章于 2025-01-12 22:37:48 发布
原创 最新推荐文章于 2025-01-12 22:37:48 发布 · 5.7k 阅读 · 1 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文介绍了一种解决Linux系统中因误删libc.so.6导致busybox命令失效的方法。通过设置LD_PRELOAD环境变量预加载libc库，绕过共享库缺失的问题，确保系统和服务的正常运行。


偶然错误的将linux系统中的libc.so.6链接删除，导致busybox所有cmd命令失效，报load library error.最终的解决方法是采用预加载库的方式来解决这个问题：


LD_PRELOAD=/lib/libc-2.6.1.so ln -s /lib/libc-2.6.1.so libc.so.6
根据shell/exec加载elf程序的原理，是先解析ELF，定位并加载ld-linux.so这个程序加载器（该so路径需要通过ELF直接确定,且不依赖其他库），然后再解析elf中需要load的共享库，但这之前可以通过LD_PRELOAD来提前预先加载共享库，如果程序允许需要的未初始化symbol在预加载库中的话，就不会再load needed的共享库（如果预先加载的库也不满足运行需要，则继续根据编译时symbol所needed关系来load对应的so库，如果库查找后不存在就报load error。
预先加载so库的好处：避免了程序运行时所谓的库缺失,可以理解为是一种半自动的so加载过程，需要LD_PRELOAD变量来指定真实的库路径。当前，所有一切的功劳都是ld-linux的魅力所在。

ubuntu nVidia Docker环境下升级ld-2.31.so, libc-2.31.so, libpthread-2.31.so 解决GLIBC_2.28找不到问题
weixin_40592935的博客
02-11 2802
ubuntu nVidia Docker环境下升级ld-2.31.so, libc-2.31.so, libpthread-2.31.so 解决GLIBC_2.28找不到问题
Ubuntu | ERROR: ld.so: object ‘/usr/lib64/libthread.so.1‘ from /etc/ld.so.preload cannot be preloade
我是一块小石头
02-07 4126
错误一览 ERROR: ld.so: object '/usr/lib64/libthread.so.1' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored. root@xxx:~# root@xxx:~# ls ERROR: ld.so: object '/usr/lib64/libthread.so.1' from /etc/ld.so.preload cannot be prel
解决软链接问题
小小何先生的学习之旅
11-22 1447
类似这种问题 //usr/lib/x86_64-linux-gnu/libSM.so.6：对‘uuid_generate@UUID_1.0’未定义的引用 解决方法如下： 定位软件包的位置 locate libSM.so.6 删掉软链接： rm -rf /home/zhiqianghe/anaconda3/envs/kinetic/lib/libuuid.so.1 重新链接： ...
JS预加载库PxLoader.zip
07-16
PxLoader 是一个 JavaScript 库用于帮助你实现图片、声音等各种文件的预加载功能。 标签：PxLoader
【Linux】LD_PRELOAD用法
热门推荐
Making Life Better. Making Others Better.
11-20 2万+
LD_PRELOAD，是个环境变量，用于动态库的加载，动态库加载的优先级最高，一般情况下，其加载顺序为LD_PRELOAD>LD_LIBRARY_PATH>/etc/ld.so.cache>/lib>/usr/lib。程序中我们经常要调用一些外部库的函数，以malloc为例，如果我们有个自定义的malloc函数，把它编译成动态库后，通过LD_PRELOAD加载，当程序中调用malloc函数时，调用的
Linux下的预加载库，在什么情况下，不会起作用？
oqqWang1234567的专栏
04-23 318
Setuid或Setgid程序：由于安全原因，如果预加载库不在保护清单列表中，那么由setuid或setgid权限启动的程序将不会加载预加载库。程序使用dlopen()函数加载库：dlopen()函数加载的库将不会受到预加载默认路径的限制，所以预加载库将不会对这些库起作用。程序指定了完整的路径：如果程序在链接时已经指定了库的完整路径名，那么预加载库将不会起作用。总之，在上述情况下，预加载库可能会失效，需要开发者根据实际情况进行具体的调试和排查。
Linux 环境变量LD_PRELOAD
小立仔
06-12 5169
Linux 下使用 环境变量 LD_PRELOAD 简介以及使用其来 hook标准库中的函数
麒麟版WPS安装包：wps-office-12.1.2.22571.AK.preread.sw-480057-amd64.deb
10-13
麒麟版WPS安装包：wps-office_12.1.2.22571.AK.preread.sw_480057_amd64.deb
[Go运行问题]/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_xx‘ not found
安安爸Chris的专栏
04-02 2647
在一台ubuntu 20的机器上通过go 编译生成的可执行程序(使用了cgo)，在其他ubuntu机器上运行时出现如下问题。
用LD_PRELOAD加载jemalloc
sunny_98_98的博客
11-01 1969
在使用CentOS 7.6，用LD_PRELOAD方法测试了一下jemalloc 和 glibc自带的malloc的性能，发现的确更好。 为何没有测试 tcmalloc？因为从网上查了一下，tcmalloc 和 jemalloc的对比 (原文) ： 作为基础库的ptmalloc是最为稳定的内存管理器，无论在什么环境下都能适应，但是分配效率相对较低。 tcmalloc针对多核情况有所优化，性能有所提高，但是内存占用稍高，大内存分配容易出现CPU飙升。 jemalloc的内存占用更高，但是在多核多线程下的表
使用LD_PRELOAD注入程序.pdf
04-26
linux 如何hook 任何一个目标文件中 使用的 第一层函数。在没有目标源码的情形下。对目标进行hook、 亲测，可以用
Linux Reverse(1)-LD_PRELOAD
lzx13290757580的博客
09-28 868
LD_PRELOAD是 Linux 系统中的一个环境变量，它允许用户在程序运行时动态地加载共享库。通过设置该环境变量，用户可以指定一个或多个共享库，这些库中的函数将在其他库或程序调用相同函数时优先使用。这在调试、注入、替换函数实现或修改程序行为时非常有用。
【Ubuntu】LD_PRELOAD用法
静谧、淡雅
06-24 1631
LD_PRELOAD用法 LD_PRELOAD，是个环境变量，用于动态库的加载，它可以影响程序的运行时的链接（Runtime linker），它允许定义在程序运行前优先加载的动态链接库。这个功能主要就是用来有选择性的载入不同动态链接库中的相同函数。动态库加载的优先级最高。一般情况下，其加载顺序为： LD_PRELOAD>LD_LIBRARY_PATH>/etc/ld.so.cache>/lib>/usr/lib 程序中经常要调用一些外部库的函数，以mall......
linux 预加载 动态链接库rootkit 简介
whatday的专栏
09-30 1430
目录 一、动态链接库预加载型rootkit概述 二、动态链接库预加载型rootkit所用技术 2.1linux动态链接库预加载机制 2.2全局符号介入 2.3 rootkit利用的技术点 三、动态链接库预加载型rootkit 3.1利用LD_PRELOAD加载恶意动态链接库 3.2 利用/etc/ld.so.preload加载恶意动态链接库 3.3 修改动态链接器来实现恶意功能 四、通用检测方法总结 五、引用 一、动态链接库预加载型rootkit概述 动态链接库预加载机制是...
linux LD_PRELOAD 预加载 so 简介
whatday的专栏
09-30 1万+
预加载so的两种方式： 修改/etc/ld.so.preload配置文件，这种方法对配置修改之后运行的进程生效，而无法影响已经在运行的进程； 启动进程前设置LD_PRELOAD变量(如shell中执行LD_PRELOAD=/lib64/inject.so ./myprocess)，则只对当前进程生效。 默认情况下进程创建的子进程也会继承Preload环境变量，而父进程可以在子进程初始化前修改子进程的环境变量，从而避免往子代传播。 LD_PRELOAD可以影响程序的运行时的链接，它允许你定义在程序运行前
LD_PRELOAD环境变量利用
m0_67170526的博客
01-12 1285
LD_PRELOAD环境变量在ctf中的利用
ld-linux.so预加载库,绝命中的一助linux程序加载器ld-linux.so中的LD_PRELOAD预加载库...
weixin_35566895的博客
05-15 337
偶然错误的将linux系统中的libc.so.6链接删除，导致busybox所有cmd命令失效，报load library error.最终的解决方法是采用预加载库的方式来解决这个问题：LD_PRELOAD=/lib/libc-2.6.1.so ln -s /lib/libc-2.6.1.so libc.so.6根据shell/exec加载elf程序的原理，是先解析ELF，定位并加载ld-li...
ld-linux.so预加载库,如何使用LD_PRELOAD检查是否已预加载Linux共享库
weixin_33056525的博客
05-15 261
我熟悉使用dlopen()检查共享库是否已经使用先前调用dlopen()加载到进程中,如果不存在则不会触发加载,如下所示：void* lib = dlopen(lib_name,RTLD_NOLOAD);if (lib != NULL) {...}我最近尝试应用相同的模式来确定是否已使用LD_PRELOAD将少数共享库中的一个加载到进程空间中.但是在所有情况下,上面提到的对dlopen()的调用都...
Linux LD_PRELOAD优先加载so失效原因分析
xuyun0565的专栏
08-12 1065
如果stick权限的LD_PRELOAD生效，那么linux上的提权太简单了，只要将自己的代码编译成so让具有stick权限的程序运行，既可用root身份运行自己代码，因此LD_PRELOAD在遇到stick权限时必须失效。可以看出passwd的属主是root，且用于stick权限，上图中的s，这就让普通用户执行passwd命令是，passwd对应的进程具有root权限，从而到达修改/etc/shadow文件的效果。说了这么多是为了给具有stick权限的程序LD_PRELOAD不生效做铺垫，
python ../../batch_process/PreEdit.py -c PreEdit_Linux_campus01.ini python: relocation error: ../Linux/libc.so.6: symbol _dl_starting_up version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference
最新发布
10-16
<think>我们正在处理一个动态链接错误，错误信息指向GLIBC（GNU C Library）的符号问题。具体错误是： `relocation error: ../Linux/libc.so.6: symbol _dl_starting_up version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference` 这个错误通常表明系统中使用的动态链接器（ld-linux-x86-64.so.2）与C库（libc.so.6）版本不兼容。可能的原因是系统中存在多个版本的GLIBC，或者环境变量（如LD_LIBRARY_PATH）指向了错误的库路径。 ### 解决步骤 1. **检查GLIBC版本** 首先，检查当前系统的GLIBC版本。使用以下命令： ```bash ldd --version ``` 这将显示当前使用的动态链接器（ldd）和GLIBC的版本。确保系统中没有多个版本的GLIBC冲突。 2. **检查环境变量** 环境变量`LD_LIBRARY_PATH`可能会覆盖默认的库搜索路径。运行脚本前，尝试清除该变量： ```bash unset LD_LIBRARY_PATH ``` 然后再次运行脚本，看是否解决问题。 3. **检查脚本依赖的库** 使用`ldd`命令检查脚本依赖的库。首先找到Python解释器的路径，然后检查： ```bash which python # 或者 which python3 ``` 假设Python路径为`/usr/bin/python`，运行： ```bash ldd /usr/bin/python ``` 特别注意`libc.so.6`和`ld-linux-x86-64.so.2`的路径。确保它们指向正确的系统库（通常在`/lib64`或`/usr/lib64`下）。 4. **检查程序使用的动态链接器** 通过以下命令检查Python解释器使用的动态链接器： ```bash readelf -l /usr/bin/python | grep interpreter ``` 输出示例： ``` [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2] ``` 确保输出的路径正确存在。如果路径错误，可能需要重新安装Python或修复系统库。 5. **修复系统库链接** 如果发现动态链接器或libc库的链接损坏，可以尝试重建链接： ```bash # 查找ld-linux-x86-64.so.2 sudo find / -name ld-linux-x86-64.so.2 # 通常正确的路径是/lib64/ld-linux-x86-64.so.2，如果不存在，创建符号链接 sudo ln -s /lib/x86_64-linux-gnu/ld-2.31.so /lib64/ld-linux-x86-64.so.2 ``` 注意：上面的路径`ld-2.31.so`可能会根据系统版本不同而变化，请使用系统中存在的实际路径。 6. **更新系统** 如果上述步骤无效，考虑更新系统以修复潜在的软件包损坏： ```bash sudo apt update sudo apt upgrade ``` 7. **重新安装Python和相关库** 如果问题仍然存在，尝试重新安装Python和脚本依赖的库。 ### 注意事项 - 避免手动替换系统核心库（如libc），这可能导致系统不稳定。 - 如果是在容器环境中运行，检查基础镜像的兼容性。 如果以上方法都不能解决问题，请提供更多环境信息（如操作系统版本、Python版本、是否使用虚拟环境等）以便进一步分析。 §§相关问题§§ 1. 如何检查Linux系统中的动态库依赖关系？ 2. 什么是GLIBC？为什么它如此重要？ 3. 如何安全地升级或降级GLIBC？ 4. 环境变量LD_LIBRARY_PATH的作用是什么？如何正确设置它？ 5. 在Docker容器中遇到GLIBC不兼容问题该如何解决？ </think>### 问题分析 错误信息 `relocation error: ../Linux/libc.so.6: symbol _dl_starting_up version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2` 表明以下问题： 1. **GLIBC 兼容性问题**：动态链接器（`ld-linux-x86-64.so.2`）与 C 标准库（`libc.so.6`）版本不兼容，导致符号 `_dl_starting_up` 未定义[^1][^3]。 2. **路径冲突**：脚本可能调用了非系统路径的库（如 `../Linux/libc.so.6`），而非系统标准库 `/lib/x86_64-linux-gnu/libc.so.6`。 3. **环境变量干扰**：`LD_LIBRARY_PATH` 等变量可能指向了错误或冲突的库路径[^1][^2]。 --- ### 解决方案 #### 步骤 1：检查系统库路径 运行以下命令确认系统库位置： ```bash ldd --version # 查看 GLIBC 版本 ls -l /lib64/libc.so.6 # 确认标准库路径 ls -l /lib64/ld-linux-x86-64.so.2 ``` 若输出显示 `libc.so.6` 或 `ld-linux` 指向非常规路径（如 `../Linux/`），需修正链接或环境变量。 #### 步骤 2：清理冲突环境变量 临时禁用可能干扰的环境变量： ```bash unset LD_LIBRARY_PATH # 清除自定义库路径 unset LD_PRELOAD # 禁用预加载库 export PATH="/usr/bin:/bin:/usr/sbin" # 重置基础 PATH ``` 然后重新运行脚本： ```bash python ../../batch_process/PreEdit.py -c PreEdit_Linux_campus01.ini ``` #### 步骤 3：修复库符号链接 如果系统库链接异常，重建链接： ```bash # 删除旧链接（谨慎操作！） sudo rm -f /lib64/libc.so.6 /lib64/ld-linux-x86-64.so.2 # 重新链接到标准库 sudo ln -s /lib/x86_64-linux-gnu/libc-2.31.so /lib64/libc.so.6 sudo ln -s /lib64/ld-linux-x86-64.so.2 /lib64/ld-linux-x86-64.so.2 ``` > **注意**：`libc-2.31.so` 需替换为您的实际版本（通过 `ls /lib/x86_64-linux-gnu/libc-*` 查看）。 #### 步骤 4：更新系统及关键库 升级 GLIBC 和动态链接器： ```bash sudo apt update sudo apt install --reinstall libc6 libc-bin ld-linux-x86-64 ``` #### 步骤 5：检查脚本依赖 确认脚本是否硬编码了非常规库路径： ```bash grep -r "LD_LIBRARY_PATH" ../../batch_process/ # 检查脚本是否设置自定义路径 strings ../../batch_process/PreEdit.py | grep "Linux/" # 检查硬编码路径 ``` 若存在，删除或替换为系统标准路径（如 `/lib/x86_64-linux-gnu`）。 --- ### 预防措施 1. **避免手动替换系统库**：优先通过包管理器（`apt`）安装/更新库。 2. **隔离自定义环境**：使用容器（如 Docker）或虚拟环境运行脚本，避免污染系统库[^4][^5]。 3. **验证库兼容性**：运行脚本前，用 `ldd` 检查二进制文件的依赖关系： ```bash ldd ../../batch_process/PreEdit.py | grep "libc\|ld-linux" ``` > **关键提示**：若上述步骤无效，可能是系统核心库损坏，需备份数据后重装系统或使用 `Live CD` 修复[^3]。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值