security - 像这样使用环境变量是否存在任何安全问题？

Question

我正在使用具有公共(public)库的 bash 编写一组实用程序。我编写的每个脚本都必须有一段代码来确定库相对于可执行文件的路径。不是实际代码，而是示例:

#!/bin/bash

DIR="$( cd -P "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
. $DIR/../lib/utilities/functions

我没有尝试搜索库的序言，而是使用环境变量来指示库位置的好主意。

#!/bin/bash

. $TOOLS_LIBRARY_PATH

我可以使用一个包装程序来设置那个环境变量，或者我可以在我自己的路径中设置它。可能有更好的方法来组织 bash 工具集，但问题是:

我可以信任我的环境变量吗？

这就是其中之一，我从未真正想过这类问题。当使用其他语言编程时，路径用于查找库，(例如 LD_LIBRARY_PATH、PYTHONPATH、PERLLIB、RUBYLIB , CLASSPATH, NODE_PATH), 但我从来没有停下来想过这可能是不安全的。

事实上，LD_LIBRARY_PATH 有 Why LD_LIBRARY_PATH is bad以阻止其使用。如果调用它们的安全机制，则忽略 Ruby 和 Perl 库路径环境变量，$SAFE和 -T (taint mode)分别。

到目前为止我的想法...

• 用户可以将 TOOLS_PATH_LIBRARY 设置为他们选择的库，但该实用程序将在他们的 uid 下运行。他们可以简单地直接使用 bash 运行他们的恶意库。
• 我的工具 sudo 一些东西。有人可以将他们的 TOOLS_PATH_LIBRARY 设置为利用它的东西。但是，这些工具不是通过 sudo 运行的，它们只是在各处调用 sudo。在任何情况下，用户都必须是 sudoer，他们可以直接调用 sudo。
• 如果我不能信任 TOOLS_PATH_LIBRARY，那么我也不能信任 PATH。所有程序调用必须使用绝对路径。
• 我见过 shell 程序使用绝对程序的别名，因此不用调用 ls，而是使用变量，如 LS=/bin/ls。据我所知，这是为了防止用户将程序默认值重新定义为别名。请参阅:PATH, functions and security. Bash scripting best practices. .
• Perl 的 taint mode将所有环境变量视为“受污染”，这是不祥的预感，这就是我试图推理环境风险的原因。
• 一个用户不可能改变另一个用户的环境，除非该用户是根用户。因此，我只关心用户更改自己的环境以提升权限。请参阅:Is there a way to change another process's environment variables?

我已经 rubber ducked这变成了某种答案，但我仍然要发布它，因为它不是一个拍拍答案。

更新:围绕使用环境变量指定库和可执行文件路径的安全问题是什么？

Answer 1

虽然各种程序中都存在防止修改环境变量的机制，但最重要的是，不，您不能相信环境变量。安全问题是非常基本的:

只要用户可以更改预期执行的内容，就会出现漏洞被利用的可能性。

案例，看看CVE-2010-3847 .因此，对包含 setuid 或 setgid 二进制文件的文件系统具有写访问权限的低权限攻击者可以利用此缺陷提升他们的权限。它涉及用户修改的环境变量。

CVE-2011-1095是另一个例子，不涉及 SUID 二进制文件。在谷歌上搜索“glibc cve environment”，看看人们可以通过修改环境变量来做些什么。相当狡猾。

您的担忧实际上归结为您的声明:

The user could set TOOLS_PATH_LIBRARY to a library of their choosing, but the utility will run under their uid. They could simply run their malicious library directly with bash.

此处的关键词 - 运行他们的恶意库。这假设他们的库也由他们的 UID 所有。

这就是安全框架对您大有裨益的地方。我写的一篇专门针对这个问题的文章，您可以在这里找到:

https://github.com/cormander/tpe-lkm

该模块停止对可写文件或不属于受信任用户 (root) 的文件执行 execve/mmap/mprotect 调用。只要他们无法将恶意代码放入受信任用户拥有的文件/目录中，他们就无法以这种方式利用系统。

如果您正在使用包含这些变量的 SUID 二进制文件或 sudo，您可能需要考虑启用“偏执”和“严格”选项以阻止 root 用户信任非 root 用户拥有的二进制文件。

我应该提一下，这种受信任的路径执行方法可以保护二进制文件和共享库的直接执行。它对解释型语言几乎没有作用(如果有的话)，因为它们解析字节码而不是直接执行它。因此，您仍然需要一定程度地注意 PYTHONPATH、PERLLIB、CLASSPATH 等，并使用您提到的语言的安全机制。