tmpnam 警告说它很危险答案

【问题标题】：tmpnam warning saying it is dangeroustmpnam 警告说它很危险
【发布时间】：2011-03-19 00:16:41
【问题描述】：

我收到警告说 tmpnam 很危险，但我更喜欢使用它，因为它可以在 Windows 和 Linux 中按原样使用。我想知道为什么它会被认为是危险的（我猜这是因为可能被滥用，而不是它实际上无法正常工作）。

【问题讨论】：

您能添加一些上下文吗？谁声称它很危险？
tmpname 完全是变量名、文件名、源文件名还是别的什么？并非所有人都有通灵能力。
@sbi: tmpnam 是标准 C 库函数。
@Nathon 我实际上是在谈论 gcc 和 msvc，我只是想知道说它很危险的理由是什么。 @sbi 我想我应该提到它是一个标准库函数。
如果黑客有你的代码。他可以在您的代码调用 tmpnam() 之后但在您打开文件之前附加一个调试器并暂停程序。然后攻击者将修改文件系统，以便他可以访问该文件，然后让您的代码继续执行。攻击者现在可以完全访问您的 tmp 数据。或者，如果您使用 tmpfile()，则不会在代码中打开此漏洞，因为攻击者很难在代码位于操作系统的特权部分时停止代码。

【解决方案1】：

来自 tmpnam 手册页：

tmpnam() 函数每次调用都会生成一个不同的字符串，最多 TMP_MAX 次。如果调用超过 TMP_MAX 次，则行为由实现定义。

虽然 tmpnam() 生成的名称难以猜测，但在 tmpnam() 返回路径名和程序打开它的时间之间，另一个程序可能会使用 open(2 )，或将其创建为符号链接。这可能导致安全漏洞。为避免这种可能性，请使用 open(2) O_EXCL 标志打开路径名。或者更好的是，使用 mkstemp(3) 或 tmpfile(3)。

Mktemp 真正创建文件，因此您确信它可以工作，而 tmpnam 返回一个可能已经存在的名称。

【讨论】：

使用mktemp 是仅适用于Windows 的Unix，您需要tmpnam_s 和_wtmpnam_s。因此，独立于平台的版本并不那么容易。

【解决方案2】：

来自 tmpnam(3) 手册页：

虽然 tmpnam() 生成的名称难以猜测，但仍有可能在时间之间 tmpnam() 返回一个路径名，当程序打开它时，另一个程序可能会创建该路径- 使用 open(2) 命名，或将其创建为符号链接。这可能导致安全漏洞。为了避免这种可能关系，使用 open(2) O_EXCL 标志打开路径名。或者更好的是，使用 mkstemp(3) 或 tmpfile(3)。

【讨论】：

【解决方案3】：

如果你说的是 MSVC 的编译器警告：

 These functions are deprecated because more secure versions are available;
 see tmpnam_s, _wtmpnam_s.

(http://msdn.microsoft.com/de-de/library/hs3e7355(VS.80).aspx)

否则只需阅读手册页中有关此功能的缺点的内容。它主要是关于第二个进程创建与您的进程完全相同的文件名。

【讨论】：

【解决方案4】：

如果您想在多个平台上使用相同的符号，请使用宏来定义 TMPNAM。只要您选择具有相同界面的更安全的功能，您就可以在两者上使用它。无论如何，您的代码中的某处都有条件编译，对吧？

【讨论】：

【解决方案5】：

该函数很危险，因为您负责分配一个足够大的缓冲区来处理tmpnam() 将写入该缓冲区的字符串。如果您分配的缓冲区太小，tmpnam() 无法知道这一点，并且会溢出缓冲区（造成严重破坏）。 tmpnam_s()（MS 的安全版本）要求您传递缓冲区的长度，因此 tmpnam_s 知道何时停止。

【讨论】：

有一个预处理器常量 L_tmpnam 指定实现将写入的最大长度（或者在单线程程序中，您可以使用 NULL 指针，在这种情况下它将使用静态缓冲区） .因此，这是一个很容易避免的问题。危险的部分来自创建文件名和随后创建文件本身之间可能存在的竞争条件。
大多数安全漏洞都很容易避免。（您的回答引用了一种避免您描述的问题的简单方法）。如果您不遵守规则，我描述的问题更有可能发生。（也是tmpnam_s()解决的问题，所以很明显是他们考虑的问题）