有用的 GCC 标志可以提高程序的安全性吗？
纯属偶然，我偶然发现一篇文章提到您可以使用 -pie -fPIE “启用”ASLR（或者更确切地说，使您的应用程序能够感知 ASLR）。 -fstack-protector 也通常被推荐（尽管我很少看到它如何保护以及针对哪种类型的攻击的解释）。
是否有有用的选项列表以及它们如何提高安全性的解释？
...
当您的应用程序使用大约 30 个库而这些库都不使用时，这些措施到底有多大用处？ ;)
By pure chance I stumbled over an article mentioning you can "enable" ASLR with -pie -fPIE (or, rather, make your application ASLR-aware). -fstack-protector is also commonly recommended (though I rarely see explanations how and against which kinds of attacks it protects).
Is there a list of useful options and explanations how they increase the security?
...
And how useful are such measures anyway, when your application uses about 30 libraries that use none of those? ;)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
Hardened Gentoo 使用这些标志：
与默认 phoronix 基准测试套件中优化的 Gentoo linux（包括 PaX/SElinux 和其他措施，而不仅仅是 CFLAGS）相比，我发现性能下降了大约 5-10%。
Hardened Gentoo uses these flags:
I saw about 5-10% performance drop in comparison to optimized Gentoo linux (incl. PaX/SElinux and other measures, not just CFLAGS) in default phoronix benchmark suite.
至于你的最后一个问题：
PIE 仅对于能够在随机地址加载主程序来说是必需的。 ASLR 始终适用于共享库，因此无论您使用一个共享库还是 100 个共享库，PIE 的好处都是相同的。
堆栈保护器只会使使用堆栈保护器编译的代码受益，因此仅在主程序中使用它不会有帮助如果您的库充满漏洞。
无论如何，我鼓励您不要将这些选项视为应用程序的一部分，而应将其视为整个系统集成的一部分。如果您在一个将与不受信任的、潜在恶意数据交互的程序中使用 30 多个库（就代码质量和安全性而言，其中大部分可能都是垃圾），那么构建整个系统将是一个好主意具有堆栈保护器和其他安全强化选项。
但请记住，最高级别的 _FORTIFY_SOURCE 以及其他一些新的安全选项可能会破坏合法、正确的程序可能需要执行的有效操作，因此您可能需要分析它是否安全使用它们。其中一个选项所做的一件已知危险的事情（我忘了是哪一个）是使得
%n到printf的说明符不起作用，至少在某些情况下是这样。如果应用程序使用%n获取生成字符串的偏移量，并且需要使用该偏移量稍后写入其中，并且该值未填写，那么这本身就是一个潜在的漏洞。 ..As for your final question:
PIE is only necessary for the main program to be able to be loaded at a random address. ASLR always works for shared libraries, so the benefit of PIE is the same whether you're using one shared library or 100.
Stack protector will only benefit the code that's compiled with stack protector, so using it just in your main program will not help if your libraries are full of vulnerabilities.
In any case, I would encourage you not to consider these options part of your application, but instead part of the whole system integration. If you're using 30+ libraries (probably most of which are junk when it comes to code quality and security) in a program that will be interfacing with untrusted, potentially-malicious data, it would be a good idea to build your whole system with stack protector and other security hardening options.
Do keep in mind, however, that the highest levels of
_FORTIFY_SOURCEand perhaps some other new security options break valid things that legitimate, correct programs may need to do, and thus you may need to analyze whether it's safe to use them. One known-dangerous thing that one of the options does (I forget which) is making it so the%nspecifier toprintfdoes not work, at least in certain cases. If an application is using%nto get an offset into a generated string and needs to use that offset to later write in it, and the value isn't filled in, that's a potential vulnerability in itself...Debian wiki 上的强化页面至少解释了可在 Linux 上使用的最常见的内容。您的列表中至少缺少 -D_FORTIFY_SOURCE=2、-Wformat、-Wformat-security，并且对于动态加载器 relro 和 now 功能。
The Hardening page on the Debian wiki explains at least the most commons ones which are usable on Linux. Missing from your list is at least -D_FORTIFY_SOURCE=2, -Wformat, -Wformat-security, and for the dynamic loader the relro and now features.