在生产环境中使用地址无害化或其他未定义行为无害化器？

Question

在生产环境中使用地址无害化或其他未定义行为无害化器？

c++undefined-behaviorclang++address-sanitizer

5

过去人们对在某些环境中在生产中使用ASAN有所担忧：https://seclists.org/oss-sec/2016/q1/363。这是2016年的评论——今天的情况如何？

建议在用户设备上运行的生产系统中使用此处的消毒剂吗？该应用程序从其他方接收不受信任的输入，并以各种方式处理它们。

它们是否会带来安全相关的影响？添加的任何工具是否使远程利用漏洞变得更容易？

我正在考虑将此应用于开源应用程序，因此在这种情况下，简化反向工程将不是问题。

- ambiso

1

据我所知，使用这些库将导致编译器发出更多的元数据，因此启用此功能后，您的应用程序可能会更容易被黑客或逆向工程师攻击。 - 500 - Internal Server Error

2

@kiner_shah 是的 - 生产环境的意思是生产。 - ambiso

在这种情况下，我更喜欢崩溃，而不是可能存在漏洞的软件。 - ambiso

2

@KamilCuk 我明白我的问题中，“更安全”实际上是含糊不清的 - 在我的情况下，让软件崩溃比让对手自由运行（例如使用用户空指针之后）更安全。 - ambiso

@500-服务器内部错误这是一个有趣的观点，在我的情况下，源代码是公开的，所以这不会成为问题。 - ambiso

显示剩余7条评论

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- yugr · Accepted Answer

清洗工具主要是用作调试而非硬化工具，即用于验证阶段的错误检测而非生产中的错误预防。否则，它们可能会向攻击者泄露敏感信息（通过在错误时将地址空间和库版本的详细信息打印到stderr），或由于环境变量的不受控制的使用而获取本地root权限。此外，清洗工具可能会增加相当大的开销（Asan的2倍减速不罕见，UBsan的1.5倍减速）。

通常情况下，清洗工具有时会在生产环境中用于A/B测试，以增加覆盖率并检测逃脱正常QA的错误。

Clang有许多选项可用于加强安全性: fortification (-D_FORTIFY_SOURCE=2), ASLR (-fPIE), stack protection (-fstack-protector, -fsanitize=safe-stack) 和 control-flow integrity (-fsanitize=cfi) (详情请参阅Clang Hardening Cheatsheet)。它们的开销要小得多，专门用于生产环境。

更新（感谢@cisnjxqu）：UBsan 支持-fsanitize-minimal-runtime模式，提供极简、低开销的运行时库，不应增加应用程序的攻击面。