在生产中使用地址消毒剂或其他未定义行为消毒剂？

Question

过去，人们对在某些环境中的生产中使用 ASAN 存在担忧：https://seclists.org/oss-sec/2016/q1/363。评论是2016年的——今天的风景怎么样？

是否建议在用户设备上运行的生产系统中使用消毒剂？应用程序接收来自其他方的不受信任的输入，并以各种方式处理这些输入。

使用它们是否会产生与安全相关的影响？添加的任何工具实际上是否可以更轻松地远程利用错误？

我正在考虑的应用程序是开源的，因此在这种情况下简化逆向工程不会成为问题。

Answer 1

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

一般来说，消毒剂有时会在生产环境中用于 A/B 测试，以增加覆盖范围并检测正常 QA 之外的错误。

Clang 有许多强化选项：强化 ( -D_FORTIFY_SOURCE=2)、ASLR ( -fPIE)、堆栈保护 ( -fstack-protector、-fsanitize=safe-stack) 和控制流完整性 ( -fsanitize=cfi)（有关详细信息，请参阅Clang 强化备忘单）。它们的开销要小得多，并且专门用于生产。

更新（感谢@cisnjxqu）：

UBsan支持提供简约、低开销运行时库的-fsanitize-minimal-runtime模式，该库不会增加应用程序的攻击面。