为什么这么难使C不那么容易发生缓冲区溢出？

我正在大学上一门课程，其中一个实验室是对它们提供给我们的代码执行缓冲区溢出攻击。范围从简单的漏洞利用到改变堆栈上某个函数的返回地址以返回到另一个函数，一直到更改程序寄存器/内存状态然后返回到您调用的函数的代码，这意味着您调用的函数完全不会利用该漏洞。

我对此进行了一些研究，并且即使在现在，此类漏洞利用仍在很多地方使用，例如在Wii上运行自制程序以及iOS 4.3.1不受限制的越狱行为。

我的问题是为什么这个问题很难解决？显然，这是用于黑客攻击数百件事情的主要漏洞，但似乎很容易解决，只需截断超出允许长度的任何输入，然后对所有输入进行清理即可。

编辑：我想从另一个角度考虑问题-为什么C的创建者不通过重新实现库来解决这些问题？

他们确实修复了库。

任何现代C标准库中包含的更安全的变体strcpy，strcat，sprintf，等等。

在C99系统上（大多数是Unix），您会发现它们的名称类似于strncat和snprintf，“ n”表示它采用的参数是缓冲区的大小或要复制的最大元素数。

这些功能可以用来更安全地处理许多操作，但是回想起来，它们的可用性并不高。例如，某些snprintf实现不保证缓冲区为空终止。strncat需要复制许多元素，但是许多人错误地传递了dest缓冲区的大小。

在Windows中，人们常常发现strcat_s，sprintf_s中，“_s”后缀表示“安全”。它们也已进入C11中的C标准库，并提供了对发生溢出事件（例如截断与断言）的更多控制。

许多供应商提供了更多的非标准替代方案，例如asprintfGNU libc中的替代方案，它将自动分配适当大小的缓冲区。

您可以“仅修复C”的想法是一种误解。修复C不是问题-已经完成。问题在于修复数十年无知，疲倦或急忙的程序员编写的C代码，或者修复从安全无关紧要的上下文移植到安全重要的上下文的代码。尽管迁移到较新的编译器和标准库通常可以帮助自动识别问题，但是对标准库的任何更改都不能修复此代码。

说C实际上在设计上实际上是“容易出错的”，这并不是真的不正确。除了像这样的严重错误外gets，C语言在不失去吸引人们首先使用C的主要功能的情况下，实际上无法采用任何其他方式。

C被设计为一种系统语言，可以充当一种“便携式程序集”。C语言的主要特点是，与高级语言不同，C代码通常非常接近实际的机器代码。换句话说，++i通常只是一条inc指令，通过查看C代码，您通常可以大致了解处理器在运行时将执行的操作。

但是添加隐式边界检查会增加很多额外的开销，这些开销是程序员没有要求也可能不需要的。这种开销远远超出了存储每个数组长度所需的额外存储空间，或者超出了每次访问数组时检查数组范围的额外指令。指针算术呢？或者，如果您有一个带有指针的函数呢？运行时环境无法知道该指针是否在合法分配的内存块的范围内。为了对此进行跟踪，您需要一种严肃的运行时体系结构，该体系结构可以根据当前分配的内存块表检查每个指针，此时我们已经进入Java / C＃风格的托管运行时领域。

我认为真正的问题不在于这些类型的bug是很难解决的，但他们是很容易使：如果您使用strcpy，sprintf和朋友在（看似）最简单的方法，可以工作，那么你可能已经打开了缓冲区溢出的门。在有人利用它之前，没有人会注意到它（除非您有很好的代码审查）。现在添加一个事实，即有许多中等水平的程序员，而且大多数时候他们都在时间压力下-而且您的代码配方中充斥着缓冲区溢出，以至于很难简单地修复它们，因为他们很多，他们藏得很好。

修复缓冲区溢出很困难，因为C几乎没有提供解决问题的有用工具。这是一个基本的语言缺陷，本地缓冲区没有提供保护和它几乎，如果不是完全不可能用卓越的产品来取代他们，像C ++有没有std::vector和std::array，和很难甚至在调试模式下找到缓冲区溢出。

问题不在于C 语言。

IMO，要克服的唯一主要障碍是对C的理解很不好。在参考手册和讲义中，数十年来的不良实践和错误信息已被制度化，从一开始就毒害了每一代新一代的程序员。给学生一个简单的I / O功能（如gets¹或）的简短描述，scanf然后留给自己的设备使用。他们没有被告知这些工具在哪里或如何发生故障，或如何防止这些故障。他们没有被告知使用fgets和strtol/strtod因为这些被认为是“高级”工具。然后，他们在专业领域释放了他们的破坏力。并不是很多经验丰富的程序员对此有所了解，因为他们受到了同样的大脑损坏的教育。太疯狂了 我在这里以及在Stack Overflow和其他站点上看到了很多问题，很明显，问这个问题的人是由一个根本不知道他们在说什么的人教的，当然您不能只说“您的教授错了，”因为他是一名教授，而您只是互联网上的某个人。

然后，您会遇到很多不屑于任何答案的人群，“根据语言标准……”，因为他们在现实世界中工作，并且根据他们的看法，该标准不适用于现实世界。我可以和一个受过不良教育的人打交道，但是任何坚持要愚昧无知的人只会给这个行业带来麻烦。

如果正确地讲授该语言并着重于编写安全代码，就不会有缓冲区溢出问题。这不是“困难”，不是“高级”，只是谨慎。

是的，这真是令人大跌眼镜。

问题是管理短视而不是程序员无能的问题之一。请记住，一个90,000行的应用程序只需要一个不安全的操作即可完全不安全。在根本不安全的字符串处理之上编写的任何应用程序都是100％完美的，这几乎是不可能的，这意味着它是不安全的。

问题在于，不安全的费用没有向正确的收件人收取（销售应用程序的公司几乎永远不会退还购买价），或者在做出决定时不清楚（“我们必须运送不管在三月！”）。我可以肯定地说，如果您考虑了长期成本以及用户的成本，而不是公司的利润，那么使用C或相关语言编写的代码将更加昂贵，甚至可能如此昂贵，以至于在许多情况下，这显然是错误的选择。如今，传统观念认为这是必不可少的领域。但是，除非引入更严格的软件责任，否则这不会改变-行业内没人希望。

使用C的强大功能之一是它使您能够以自己认为合适的任何方式来操纵内存。

使用C的最大弱点之一是它使您可以按照自己认为合适的任何方式来操作内存。

任何不安全功能都有安全版本。但是，程序员和编译器并不严格强制使用它们。

为什么C的创建者不通过重新实现库来解决这些问题？

可能是因为C ++已经做到了，并且与C代码向后兼容。因此，如果您想在C代码中使用安全的字符串类型，则只需使用std :: string并使用C ++编译器编写C代码即可。

底层的内存子系统可以通过引入保护块并对其进行有效性检查来帮助防止缓冲区溢出-因此所有分配都添加了4个字节的“ fefefefe”，当写入这些块时，系统会抛出摆动。它不能保证防止内存写入，但是它将表明出了点问题，需要修复。

我认为问题在于旧的strcpy等例程仍然存在。如果删除它们以支持strncpy等，那将有所帮助。

很容易理解为什么无法解决溢出问题。C在几个方面存在缺陷。当时，这些缺陷被视为可以容忍甚至是功能。几十年后的今天，这些缺陷是无法修复的。

编程社区的某些部分不希望这些漏洞被堵塞。只需看看所有从字符串，数组，指针，垃圾回收开始的火焰之战...