“LD_LIBRARY_PATH”是否存在安全风险？

Question

我们知道ld.so在环境变量指定的目录中搜索库$LD_LIBRARY_PATH，但普通用户可以运行：

export LD_LIBRARY_PATH=dir1:dir2...

他们可以将受感染的库保存在比原始库优先级更高的路径中，以便ld.so找到该库而不是原始库中的受信任库ld.so.cache。

这有风险吗？
我们如何才能禁止普通用户写入此环境变量？

Answer 1

这根本不是一个安全风险，因为您始终只能为当前环境（例如当前 Bash 会话）设置环境变量，并且使用该export命令为其子环境（您启动的脚本、子 shell 等）设置环境变量。无法将创建或修改的环境变量升级到父环境中。当然，这包括普通用户无法进行系统范围的更改。

因此，如果您运行，唯一会受到影响的环境export LD_LIBRARY_PATH=...是您当前的 shell 以及您稍后可能生成的任何子 shell。假设您更改查找路径以在开头包含受感染的库，即具有最高优先级。然后您运行一个可执行文件，它会在不知情的情况下加载其中一个受感染的库。现在会发生什么？

您的恶意代码（来自受感染的库）以常规非管理员权限在您自己的用户帐户下运行。这听起来可能很糟糕，但实际上……那又怎么样？它以常规用户权限运行，这再次意味着它无法影响整个系统。顺便说一句，直接运行具有相同恶意代码的可执行文件比修改库查找路径并等待正常的可执行文件加载它要容易得多。

结论：普通用户只能修改自己的库查找路径，这意味着他们也只能在具有常规非系统范围权限的普通用户帐户下自行加载这些库。也就是说，强制加载受感染的库还是直接运行受感染的可执行文件都没有区别。如果用户无法覆盖该环境变量，您将一无所获。

附言：还有一些可执行文件具有设置用户标识或者设置组ID标志设置，这意味着它们将不会以运行它们的人的用户/组的身份运行，而是以拥有它们。例如，sudo可执行文件由 root 拥有，并且具有设置用户标识标志设置，这意味着它在执行时始终以 root 身份运行。出于安全原因，$LD_LIBRARY_PATH具有以下之一的可执行文件会忽略该变量：设置用户标识/设置gid设置标志以确保普通用户不能以 root 权限运行可执行文件来加载任意库。
_{（感谢@Rinzwind 指出这一点！）}