Question

当我将argv作为参数传递给test_run()时，我使用以下代码获取Coverity警告不信任值作为参数。它说受污染的变量传递到受污染的水槽但是我不确定如何使argv没有受到污染！

#include<stdio.h>
#include<string.h>
#include<stdlib.h>

int
main (int argc, char **argv)
{

    /* some code  */

//    char **nstr;
//    nstr = malloc(sizeof(char*));
//    if(!nstr) {
//        return 1;
//    }
//    int i=0;
//    for(i=0;i<argc;i++){
//        nstr[i] = strdup(argv[i]);
//    }

      test_run(argc-1, argv, testf);

}

int test_run(int argc, char **argv, testf_handle testf)
{
    if (!argv) {
        return 1;
    }

    /* some code */

    testf->prog_name = argv[0];
    parse_context(&pc, argc, argv);

    /*- - other code - -*/

}

我尝试使用注释代码并传递nstr insted of argv但在行时仍然收到相同的警告：

nstr[i] = strdup(argv[i]);

在将其作为论据传递之前，我不确定我应该做什么样的健全检查。我在linux机器上使用gcc编译器。

testf 是结构 test_framework 的一个实例，它有几个成员变量。

感谢。

Answer 1

您可以通过检查argv使其不受污染，以确保它符合某些特定规范。例如，检查argv下字符串的长度以确保它小于某个上限，确保它不包含错误的字符序列等。

Coverity将检测您的清理尝试，一旦您真正清理您的输入，该缺陷将得到解决。

Answer 2

我没有使用Coverity，但使用过其他静态分析工具，它们彼此之间都有相似之处。

一般来说，像这样的工具是愚蠢的。当他们看到从源头到下沉的污染时，他们会发出警告，但他们无法知道数据是否已被消毒。它需要人工审核者检查警告是真实的还是（经常）是误报。

编辑： @Caleb声称Coverity可以检测数据清理 - 请参阅下面的评论。

该工具假定命令行参数（argv）等输入存在安全风险。第一个问题是，在您的申请中，这是否是一个正确的假设。如果这是测试代码（看起来可能是这样），则该假设是错误的，您可以将警告标记为误报。否则，让我们继续，理由是假设是真的。

现在Coverity正在恐慌，因为这种污点正在发生，并且它认为strdup（）可能会发生危险。这有什么危险？通常，该工具会告诉您此处的风险（例如：缓冲区溢出，因内存分配过多而导致的DoS等）。

我在这里没有看到缓冲区溢出风险，但我可能错了。由于内存分配过多，警告可能是DoS。如果这是问题，那么解决方案是编写拒绝不合理大小输入的代码。一般来说，解决方案是编写解决Coverity恐慌的问题的代码，因此您已经清理了输入。

但是，一旦您对解决方案进行了编码，Coverity可能仍然会给您相同的警告。问题是虽然您已经清理了输入，但是哑工具无法检测到。这是人工代码审查员必须介入并告诉工具处理问题的地方，因此禁止警告。

底线：这些工具可以帮助人工代码审查人员，而不是替换人工代码审查人员。如果没有人类安全专家的帮助，请不要尝试以自动方式使用它们。（编辑：@Caleb建议Coverity在纠正误报方面做得很好。）

将受感染的变量传递到污染的水槽

2 个答案: