解决“编写安全代码”中的安全错误

Question

我正在研究代码安全性，并且试图对以下两个摘录进行安全性分析，摘录自第二版“编写安全代码”：

http://www.di.uniba.it/~ndm/corsi/sa/materiale/lab/StackOverrun.c

http://www.di.uniba.it/~ndm/corsi/sa/materiale/lab/FormatString.c

在第一个中，我认为唯一不安全的语句是strcpy(buf, input); 应该是strncpy(buf, input, sizeof(buf-1)); 所有其他printf都是安全的：即使他们使用的自变量少于应该支持的自变量，它们也是故意这样做的。

在第二fprintf(stdout, buf); ， printf是安全的，但是fprintf(stdout, buf); 不是，应该用以下代码替换： fprintf(stdout, "%s", buf);

我的问题是pFile = fopen(argv[1], "r"); 由于可能的竞争条件，分析程序也将其视为不安全的，但我看不出在此代码中无法利用此方法。 如果文件以只读方式打开，攻击者可以对其进行恶意处理吗？ 我觉得不行。

所以问题是：您认为这种分析是正确的吗？ 您还能找到其他缺陷吗？还是我的推理受到了困扰？

谢谢！

Answer 1

这个清晰的描述来自Apple Development网站 ：

如果您打开一个文件然后从中读取文件，即使您的应用程序在这两个操作之间没有执行其他操作，则在打开文件之后和读取文件之前，其他一些过程也可能会更改文件。 如果两个不同的进程（在相同或不同的应用程序中）正在写入同一文件，则无法知道哪个首先写入，哪个会覆盖另一个写入的数据。 这种情况会导致安全漏洞。

可以利用两种基本的竞争条件类型：检查时间-使用时间（TOCTOU）和信号处理。

此外，如图所示的fopen（）调用未对filename进行任何清理 。 当然，您实际上不会这样做，对吗？ 绝对应该对名称进行分析，检查，并且绝对不要信任该名称，因为它是程序的参数。 理想情况下，您应该使用多个属性来标识文件

Answer 2

我的第一个想法是，将未经消毒的程序输入传递给libc调用很不好。 在很多情况下，libc会溢出，并且开发人员不应传递超出libc期望值的参数（例如，在这种情况下，字符串应为<PATH_MAX）。

但是，既然您提到了竞争条件，我认为尽管在这种特定情况下没有特别的问题，但是fopen（）的使用在一般情况下是不受欢迎的，因为它很容易出现竞争条件。 如果要寻址文件，则任何文件都使用带有文件名而不是文件句柄的函数。 如果通过一个路径或另一个操作通过文件的路径名引用文件，则文件的状态可能会更改，并且程序对该状态的假设可能不再正确。 在下面的文章中会更好地进行解释。

http://www.sans.edu/research/security-laboratory/article/race-cndtns

http://www.unixprogramming.info/s_isregfile-race-conditions