安全访问由环境变量标识的目录中的文件？ [英] Secure access to files in a directory identified by an environment variable?
问题描述
任何人都可以指出一些代码，通过环境变量指定（部分）路径来处理文件访问的安全性，特别是针对Unix及其变体，但是Windows解决方案也是有意义的？
Can anyone point to some code that deals with the security of files access via a path specified (in part) by an environment variable, specifically for Unix and its variants, but Windows solutions are also of interest?
这是一个很长的问题 - 我不知道它适合于SO范式。
考虑这种情况：
背景：
- 软件包PQR可以安装在用户选择的位置。
- 环境变量$ PQRHOME用于标识安装目录。
- 默认情况下，$ PQRHOME下的所有程序和文件属于一个特殊组pqrgrp。
- 同样，$ PQRHOME下的所有程序和文件都属于特殊用户pqrusr或用户root（那些是SUID根程序）。
- 几个程序是SUID pqrusr;更多的程序是SGID pqrgrp。
- 大多数目录由pqrusr拥有，属于pqrgrp;有些可以属于其他组，而这些组的成员可以使用该软件获得额外的权限。
- 许多特权的可执行文件必须由不是pqrgrp成员的人运行;程序必须验证用户被允许通过不直接涉及此问题的奥秘规则来运行。
- 启动后，一些特权程序必须保留其提升的权限，因为他们是长期运行的守护进程，可以在一生中代表许多用户行事。
- 由于各种神秘原因，程序无权将目录更改为$ PQRHOME。
- Software package PQR can be installed in a location chosen by users.
- The environment variable $PQRHOME is used to identify the install directory.
- By default, all programs and files under $PQRHOME belong to a special group, pqrgrp.
- Similarly, all programs and files under $PQRHOME either belong to a special user, pqrusr, or to user root (and those are SUID root programs).
- A few programs are SUID pqrusr; a few more programs are SGID pqrgrp.
- Most directories are owned by pqrusr and belong to pqrgrp; some can belong to other groups, and the members of those groups acquire extra privileges with the software.
- Many of the privileged executables must be run by people who are not members of pqrgrp; the programs have to validate that the user is permitted to run it by arcane rules that do not directly concern this question.
- After startup, some of the privileged programs have to retain their elevated privileges because they are long-running daemons that may act on behalf of many users over their lifetime.
- The programs are not authorized to change directory to $PQRHOME for a variety of arcane reasons.
当前检查：
- 程序目前检查$ PQRHOME和它下面的关键目录是安全的（由pqrusr拥有，属于pqrgrp，没有公共写入权限）。
- 此后，程序访问$ PQRHOME下的文件通过环境变量的全部值。
- 特别地，G11N和L10N通过访问安全目录中的文件，并读取printf（）等的格式字符串在这些目录中的文件中，使用完整的照片来自$ PQRHOME加上已知子结构的hname（例如$ PQRHOME / g11n / en_us / messages.l10n）。
假设$ PQRHOME的已安装值为/ opt / pqr。
Assume that the 'as installed' value of $PQRHOME is /opt/pqr.
已知攻击：
- 攻击者设置PQRHOME = / home / attacker / pqr。
- 这实际上是/ opt / pqr的符号链接，所以当一个的PQR程序，称为pqr-victim，检查目录，它具有正确的权限。
- 在安全检查成功完成后，攻击者立即更改符号链接，使其指向/ home / attacker / bogus-pqr，这显然是受到攻击者的控制。
- 当pqr-victim现在访问所谓的安全目录下的文件时，会发生事情。
- Attacker sets PQRHOME=/home/attacker/pqr.
- This is actually a symlink to /opt/pqr, so when one of the PQR programs, call it pqr-victim, checks the directory, it has correct permissions.
- Immediately after the security checking is completed successfully, the attacker changes the symlink so that it points to /home/attacker/bogus-pqr, which is clearly under the attacker's control.
- Dire things happen when the pqr-victim now accesses a file under the supposedly safe directory.
鉴于PQR目前的行为如上所述，是一个大包（数百万行代码，十多年来开发各种编码标准，经常被忽略），您将用什么技术来解决问题？
已知的选项包括：
- 将所有格式化调用更改为使用根据格式字符串检查实际参数的函数，并附加一个参数，指示传递给函数的实际类型。 （这是棘手的，并且由于要更改的格式操作的数量太多，可能会出现错误 - 但是如果检查功能本身是正确的，则可以正常工作。）
- 建立直接路径PQRHOME并验证其安全性（下面的详细信息），如果不安全，拒绝启动，然后使用直接路径而不是$ PQRHOME的值（当它们不同时）。 （这需要使用$ PQRHOME的所有文件操作不使用getenv（）的值，而是使用映射的路径。例如，这将要求软件确定/ home / attacker / pqr是/ opt / pqr的符号链接， / opt / pqr的路径是安全的，此后，每当文件被引用为$ PQRHOME / some / thing时，所使用的名称将是/ opt / pqr / some / thing而不是/ home / attacker / pqr / some /东西，这是一个很大的代码库 - 不是很简单的修复。）
- 确保$ PQRHOME上的所有目录（甚至跟踪符号链接）都是安全的（再次下面的细节）如果有什么不安全的话，软件将拒绝启动。
- 硬编码软件安装位置的路径。 （这不会工作PQR;如果没有其他的话，它会使测试失败，对于用户来说，这意味着它们可以安装一个版本，升级等需要并行运行，这对于PQR来说不起作用。）
- Change all formatting calls to use function that checks actual arguments against the format strings, with an extra argument indicating the actual types passed to the function. (This is tricky, and potentially error prone because of the sheer number of format operations to be changed - but if the checking function is itself sound, works well.)
- Establish the direct path to PQRHOME and validate it for security (details below), refusing to start if it is not secure, and thereafter using the direct path and not the value of $PQRHOME (when they differ). (This requires all file operations that use $PQRHOME to use not the value from getenv() but the mapped path. For example, this would require the software to establish that /home/attacker/pqr is a symlink to /opt/pqr, that the path to /opt/pqr is secure, and thereafter, whenever a file is referenced as $PQRHOME/some/thing, the name used would be /opt/pqr/some/thing and not /home/attacker/pqr/some/thing. This is a large code base - not trivial to fix.)
- Ensure that all directories on $PQRHOME, even tracking through symlinks, are secure (details below, again), and the software refuses to start if anything is insecure.
- Hard-code the path to the software install location. (This won't work PQR; it makes testing hell, if nothing else. For users, it means they can have but one version installed, and upgrades etc require parallel running. This does not work for PQR.)
安全路径的建议标准：
- 对于每个目录，所有者必须被信任。 （理由：所有者可以随时更改权限，因此所有者必须被信任，不得随意更改，从而破坏软件的安全性。
- 对于每个目录，组必须不具有写入权限（因此该组的成员不能修改目录内容）或该组必须被信任。 （理由：如果组成员可以修改该目录，那么它们可能会破坏软件的安全性，因此无论是否可以更改它，或者必须信任它才能更改它。）
- 对于每个目录，其他人对目录不得有写入权限。
- 默认情况下，用户root，bin，sys和默认情况下，GID = 0的组（俗称为root，wheel或system），bin，sys和pqrgrp可以被信任（其中bin和sys存在）。
- 被信任另外，拥有根目录的组（在MacOS X上称为admin）可以被信任。
- For each directory, the owner must be trusted. (Rationale: the owner can change permissions at any time, so the owner must be trusted not to make changes at random that break the security of the software.)
- For each directory, the group must either not have write privileges (so members of the group cannot modify the directory contents) or the group must be trusted. (Rationale: if the group members can modify the directory, then they can break the security of the software, so either they must be unable to change it, or they must be trusted not to changed it.)
- For each directory, 'others' must have no write privilege on the directory.
- By default, the users root, bin, sys, and pqrusr can be trusted (where bin and sys exist).
- By default, the group with GID=0 (variously known as root, wheel or system), bin, sys, and pqrgrp can be trusted. Additionally, the group that owns the root directory (which is called admin on MacOS X) can be trusted.
POSIX函数 realpath（）提供一个映射服务，将/ home / attacker / pqr映射到/ opt / pqr;它不会进行安全检查，但这只能在解决的路径上进行。
The POSIX function realpath() provides a mapping service that will map /home/attacker/pqr to /opt/pqr; it does not do the security checking, but that need only be done on the resolved path.
所以，以所有这些为背景，是否有任何已知的软件它通过模糊相关的回旋来确保其安全？这是过度偏执吗？ （如果是，为什么 - 你真的确定吗？）
已编辑：
感谢各种评论。
@ S.Lott：攻击（在问题中概述）意味着至少有一个setuid根程序可以使用（非特权）用户选择的格式字符串，并且可以至少崩溃程序，因此最可能获取根shell。幸运的是需要本地shell访问;它不是一个远程攻击。它需要不可忽略的知识量到达那里，但是我认为这种专业知识不是在那里，这是不明智的。
@S.Lott: The attack (outlined in the question) means that at least one setuid root program can be made to use a format string of the (unprivileged) user's choosing, and can at least crash the program and therefore most probably can acquire a root shell. It requires local shell access, fortunately; it is not a remote attack. It requires a non-negligible amount of knowledge to get there, but I consider it unwise to assume that the expertise is not 'out there'.
那么， m描述是一个格式字符串漏洞，已知的攻击路径涉及伪造程序，以便尽管它认为它正在访问安全的邮件文件，但它实际上是使用受控制的消息文件（包含格式字符串）的用户，不在软件的控制之下。
So, what I'm describing is a 'format string vulnerability' and the known attack path involves faking the program out so that although it thinks it is accessing secure message files, it actually goes and uses the message files (which contain format strings) that are under the control of the user, not under the control of the software.
推荐答案
如果您为 $ PQRHOME 解决实际路径并检查其安全性。这样你的代码很少需要改变。
Option 2 works, if you write a new value for $PQRHOME after resolving its real path and check its security. That way very little of your code needs changing thereafter.
就保持setuid权限而言，如果你可以做某种特权分离，这将有所帮助涉及真实用户输入的操作在真实的uid下运行。特权进程和实际流程然后使用 socketpair 或类似的东西进行交谈。
As far as keeping the setuid privileges, it would help if you can do some sort of privilege separation, so that any operations involving input from the real user runs under the real uid. The privileged process and the real-uid process then talk using a socketpair or something like it.
这篇关于安全访问由环境变量标识的目录中的文件？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
