ldd命令可能导致运行恶意代码
Posted 王万林 Ben
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了ldd命令可能导致运行恶意代码相关的知识,希望对你有一定的参考价值。
ldd命令可能导致运行恶意代码
前言
ldd这个系统命令,是linux用户常用的一个命令,它可以打印出共享库依赖情况。
一、ldd为什么可能导致运行恶意代码
从ldd(1)手册可以知道,通过设置一个特殊变量LD_TRACE_LOADED_OBJECTS,然后执行程序工作,不可信的程序可能强制执行ldd的用户运行任意代码。因此,不要使用ldd查看不可信的程序的共享库依赖情况。
二、简单的例子
$ ldd /bin/ls
librt.so.1 => /lib/librt.so.1 (0x4001d000)
libc.so.6 => /lib/libc.so.6 (0x4002e000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40149000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
LD_TRACE_LOADED_OBJECTS变量设置为1
$ LD_TRACE_LOADED_OBJECTS=1 /bin/ls
librt.so.1 => /lib/librt.so.1 (0x4001d000)
libc.so.6 => /lib/libc.so.6 (0x4002e000)
libpthread.so.0 => /lib/libpthread.so.0 (0x40149000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
这就是glibc program interpreter如何工作的。其它呢?我们来对比一下glibc与uclibc。
先写一段小程序
$ echo 'main() { printf("hello world\\n"); }' > hello.c
首先glibc
$ gcc hello.c -o gcc_hello
$ ldd ./gcc_hello
libc.so.6 => /lib/libc.so.6 (0x4001d000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
然后uclibc
$ i386-uclibc-gcc hello.c -o uclibc_hello
$ ldd ./uclibc_hello
hello world
这里没有打印我们想要的共享库依赖情况,而是直接执行了程序。
有了上述的基本了解,我们来看看恶意程序将如何伪装自己?
假设我们有这么一段程序
$ cat nasty.c
int main()
{
if (getenv("LD_TRACE_LOADED_OBJECTS") != 0) {
/* we are being executed under ldd */
printf("doing funny stuff\\n");
printf("\\tlibc.so.6 => /lib/libc.so.6 (0x4001d000)\\n");
printf("\\t/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)\\n");
return 0;
}
printf("normally program execution\\n");
return 0;
}
使用uclibc编译
$ i386-uclibc-gcc nasty.c -o nasty
$ ldd ./nasty
doing funny stuff
libc.so.6 => /lib/libc.so.6 (0x4001d000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
可以看到有伪装的共享依赖库信息输出。
总结
因此在做程序分析时,一定要在隔离,受保护的环境下进行。尤其是使用特权账号,更要注意。
参考资料
https://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
http://reverse.lostrealm.com/protect/ldd.html
以上是关于ldd命令可能导致运行恶意代码的主要内容,如果未能解决你的问题,请参考以下文章
对“xxx”类型的已垃圾回收委托进行了回调。这可能会导致应用程序崩溃损坏和数据丢失。向非托管代码传递委托时,托管应用程序必须让这些委托保持活动状态,直到确信不会再次调用它们。 错误解决一例。(代码片段