【问题标题】:Detecting and intercepting linked library dependencies at runtime在运行时检测和拦截链接库依赖项
【发布时间】:2015-05-16 12:41:35
【问题描述】:

在 UNIX 系统上是否有一种简单的方法来识别动态(共享)库是否依赖于其他动态库?

我正在探索系统级 API,例如 dlopen 和 C 和 C++ 中的朋友。我有一个受控环境,我将在其中调用dlopen 并映射特定功能。这个想法是人们将能够为应用程序编写本机插件(让我们暂时假设确保库实际执行正确的功能并且没有恶意符合作者的最大利益)。

但是,作为一项安全措施,我想确保在运行时加载的动态库不会链接到任何其他动态库(目的是禁止系统调用,只允许来自本地数学库的函数) - 如果是的,不要加载它。

我提出的一些(冗长和/或困难的)解决方案:

  • 编写一个编译器 shim,它使用一组非常特定的编译器选项编译插件代码,并注入某种校验和函数,可用于验证是否使用了编译器 shim。
  • 单独切出所有引用我不想使用的函数名称的函数调用。
  • 使用一些链接器路径技巧来拦截所有系统调用。

是否有检查动态库依赖关系的简单(r)方法?

【问题讨论】:

  • 从安全的角度来看,不加载外部库不会阻止系统调用。如果您担心的话,恶意程序员可以在 C/C++ 中做太多事情而无需任何操作。但是,上面的评论是对的,ldd 可能是最好的选择。不过,据我所知,它不会对标准库调用的使用提供任何暗示,因为它们本身就有很大的破坏潜力。

标签: c++ c unix shared-libraries dynamic-linking


【解决方案1】:

但是,作为一项安全措施,我想确保在运行时加载的动态库不会链接到任何其他动态库

请注意,动态库可以在显式链接到任何其他动态库的情况下导入符号。例如:

int foo() { return open("/etc/passwd", O_RDONLY); }

gcc -fPIC -shared -o foo.so foo.c -nostdlib

现在foo.so 没有任何DT_NEEDED 共享库依赖项,但仍会随意open /etc/passwd

(目的是禁止系统调用,只允许本地数学库中的函数)- 如果是,请不要加载它。

你的意图有很多错误,这甚至不好笑。

首先,您不需要链接到任何外部库来直接执行系统调用,它可以在汇编中轻松完成。

此外,该插件可以查找和修改动态加载器的数据,一旦这样做,它就可以让你的主程序做任何事情。例如,它可以劫持你所有的主程序调用到libc.so,并将它们重定向到别处。

一旦您在进程中运行不受信任的代码,它游戏结束

我想出的解决方案

他们都没有机会工作。你花在这上面的任何时间都是浪费时间。

【讨论】:

  • 感谢您的意见。但是,我认为花在教育上的任何时间都不是浪费时间。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-01-18
  • 1970-01-01
  • 2011-10-31
  • 2020-03-15
相关资源
最近更新 更多