缓冲区溢出攻击的防范技术有哪些？
防止缓冲区溢出攻击的思路是什么？我听说过 Stackguard，但到目前为止，这个问题是否通过应用 Stackguard 或与其他技术相结合来完全解决？
热身之后，作为一名有经验的程序员
你认为为什么会这样 难以提供充足 缓冲区溢出攻击的防御？
编辑：感谢所有答案并保持安全标签处于活动状态:)
what are the ideas of preventing buffer overflow attacks? and i heard about Stackguard,but until now is this problem completely solved by applying stackguard or combination of it with other techniques?
after warm up, as an experienced programmer
Why do you think that it is so
difficult to provide adequate
defenses for buffer overflow attacks?
Edit: thanks for all answers and keeping security tag active:)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
您可以做很多事情。没有特定的顺序...
首先，如果您的语言选择在允许直接内存访问的语言和不允许直接内存访问的语言之间平均分配（或接近平均分配），请选择不允许的语言。也就是说，使用 Perl、Python、Lisp、Java 等而不是 C/C++。这并不总是一个选择，但它确实有助于防止你搬起石头砸自己的脚。
其次，在可以直接访问内存的语言中，如果有可以为您处理内存的类（例如 std::string），请使用它们。与用户较少的课程相比，更喜欢练习良好的课程。更多的使用意味着更简单的问题更有可能在日常使用中被发现。
第三，使用 ASLR 和 DEP 等编译器选项。使用您的应用程序提供的任何与安全相关的编译器选项。这不会防止缓冲区溢出，但有助于减轻溢出的影响。
第四，使用静态代码分析工具（例如 Fortify、Qualys 或 Veracode 的服务）来发现您无意编码的溢出。然后修复发现的东西。
第五，了解溢出是如何工作的，以及如何在代码中发现它们。你所有的同事也应该学习这一点。创建一个组织范围内的政策，要求人们接受关于超限（和其他漏洞）如何工作的培训。
第六，将安全代码审查与常规代码审查分开进行。定期进行代码审查可确保代码有效、通过功能测试并符合编码策略（缩进、命名约定等）。安全代码审查是专门、明确且仅旨在查找安全问题的。尽可能对所有代码进行安全代码审查。如果您必须确定优先级，请从关键任务的东西开始，这些东西可能会出现问题（跨越信任边界的地方（了解数据流图和威胁模型并创建它们），使用解释器的地方，特别是传递用户输入的地方/存储/检索，包括从数据库检索的数据）。
第七，如果你有钱，请聘请像Neohapsis、VSR、Matasano等好的顾问来审查你的产品。他们会发现不仅仅是超支，而且您的产品也会因此而变得更好。
第八，确保您的 QA 团队了解超限是如何工作的以及如何对其进行测试。 QA 应该有专门设计的测试用例来发现所有输入中的超限。
第九，进行模糊测试。模糊测试在许多产品中发现了数量惊人的溢出。
编辑添加：我读错了问题。标题说“有什么技巧”，但正文说“为什么很难”。
这很难，因为很容易犯错误。小错误（例如相差一错误或数字转换）可能会导致溢出。程序是复杂的野兽，具有复杂的交互。哪里有复杂性，哪里就会出现问题。
或者，把问题转回到你身上：为什么编写无错误的代码如此困难？
There's a bunch of things you can do. In no particular order...
First, if your language choices are equally split (or close to equally split) between one that allows direct memory access and one that doesn't , choose the one that doesn't. That is, use Perl, Python, Lisp, Java, etc over C/C++. This isn't always an option, but it does help prevent you from shooting yourself in the foot.
Second, in languages where you have direct memory access, if classes are available that handle the memory for you, like std::string, use them. Prefer well exercised classes to classes that have fewer users. More use means that simpler problems are more likely to have been discovered in regular usage.
Third, use compiler options like ASLR and DEP. Use any security related compiler options that your application offers. This won't prevent buffer overflows, but will help mitigate the impact of any overflows.
Fourth, use static code analysis tools like Fortify, Qualys, or Veracode's service to discover overflows that you didn't mean to code. Then fix the stuff that's discovered.
Fifth, learn how overflows work, and how to spot them in code. All your coworkers should learn this, too. Create an organization-wide policy that requires people be trained in how overruns (and other vulns) work.
Sixth, do secure code reviews separately from regular code reviews. Regular code reviews make sure code works, that it passes functional tests, and that it meets coding policy (indentation, naming conventions, etc). Secure code reviews are specifically, explicitly, and only intended to look for security issues. Do secure code reviews on all code that you can. If you have to prioritize, start with mission critical stuff, stuff where problems are likely (where trust boundaries are crossed (learn about data flow diagrams and threat models and create them), where interpreters are used, and especially where user input is passed/stored/retrieved, including data retrieved from your database).
Seventh, if you have the money, hire a good consultant like Neohapsis, VSR, Matasano, etc. to review your product. They'll find far more than overruns, and your product will be all the better for it.
Eighth, make sure your QA team knows how overruns work and how to test for them. QA should have test cases specifically designed to find overruns in all inputs.
Ninth, do fuzzing. Fuzzing finds an amazingly large number of overflows in many products.
Edited to add: I misread the question. THe title says, "what are the techniques" but the text says "why is it hard".
It's hard because it's so easy to make a mistake. Little mistakes, like off-by-one errors or numeric conversions, can lead to overflows. Programs are complex beassts, with complex interactions. Where there's complexity there's problems.
Or, to turn the question back on you: why is it so hard to write bug-free code?
可以防止缓冲区溢出漏洞。如果程序员是完美的，就不会有
未经检查的缓冲区，因此没有缓冲区溢出漏洞。然而，程序员并不是
完美的、未经检查的缓冲区继续大量存在。
Buffer overflow exploits can be prevented. If programmers were perfect, there would be no
unchecked buffers, and consequently, no buffer overflow exploits. However, programmers are not
perfect, and unchecked buffers continue to abound.
只需要一种技术：不要信任来自外部来源的数据。
Only one technique is necessary: Don't trust data from external sources.
安全性没有灵丹妙药：您必须仔细设计、仔细编码、进行代码审查、测试并安排在出现漏洞时修复它们。
幸运的是，缓冲区溢出的具体情况长期以来一直是一个已解决的问题。大多数编程语言都有数组边界检查并且不允许程序组成指针。只是不要使用少数允许缓冲区溢出的语言，例如 C 和 C++。
当然，这适用于整个软件堆栈，从嵌入式固件1开始到您的应用程序。
1 对于那些不熟悉所涉及技术的人来说，此漏洞可以让网络上的攻击者唤醒并控制已关闭电源的计算机。 （典型的防火墙配置会阻止违规数据包。）
There's no magic bullet for security: you have to design carefully, code carefully, hold code reviews, test, and arrange to fix vulnerabilities as they arise.
Fortunately, the specific case of buffer overflows has been a solved problem for a long time. Most programming languages have array bounds checking and do not allow programs to make up pointers. Just don't use the few that permit buffer overflows, such as C and C++.
Of course, this applies to the whole software stack, from embedded firmware¹ up to your application.
¹ For those of you not familiar with the technologies involved, this exploit can allow an attacker on the network to wake up and take control of a powered off computer. (Typical firewall configurations block the offending packets.)
您可以运行分析器来帮助您在代码投入生产之前发现问题。我们的内存安全检查器将发现缓冲区溢出、坏指针错误、数组访问错误和内存管理错误在 C 代码中，通过检测代码以在出现错误时进行监视。如果您希望 C 程序不受此类错误的影响，您可以简单地使用内存安全分析器的结果作为代码的生产版本。
You can run analyzers to help you find problems before the code goes into production. Our Memory Safety Checker will find buffer overuns, bad pointer faults, array access errors, and memory management mistakes in C code, by instrumenting your code to watch for mistakes at the moment they are made. If you want the C program to be impervious to such errors, you can simply use the results of the Memory Safety analyzer as the production version of your code.
在现代开发中，三大要素是：
ASLR
金丝雀
NX 位 a>
GCC 的现代版本默认应用 Canary。并非所有 ASLR 都是一样的，Windows 7、Linux 和 *BSD 都有一些最好的 ASLR。 OSX 的 ASLR 实现是迄今为止最差的，绕过它很简单。一些 最先进的缓冲区溢出攻击使用奇特的方法来绕过 ASLR。 NX Bit 是迄今为止最简单的绕过返回 libc 风格攻击的方法，这对于漏洞开发人员来说不是问题。
In modern exploitation the big three are:
ASLR
Canary
NX Bit
Modern builds of GCC applies Canaries by default. Not all ASLR is created equally, Windows 7, Linux and *BSD have some of the best ASLR. OSX has by far the worst ASLR implementation, its trivial to bypass. Some of the most advanced buffer overflow attacks use exotic methods to bypass ASLR. The NX Bit is by far the easist method to byapss, return-to-libc style attacks make it a non-issue for exploit developers.