每年最早召开的安全会议之一的NDSS即将在本月底迎来2024的版本，在今年的论文中，有一篇关注密码学误用的研究论文Towards Precise Reporting of Cryptographic Misuses，我们今天要推荐给大家。这篇论文也通过了NDSS的Artifact Evaluation，方便大家验证结果。
在软件工程研究社区，大家对于代码静态分析工具的态度似乎是“宁可错杀一千，不可错过一个”。也就是说，最好不要有漏报（false negative）。但是安全研究社区（以及现实生活中的开发者）觉得太多的误报（false positive）反而会让人觉得暴躁，进而忽视一切的警告。今天这篇论文作者也表达了类似的观点，他们针对现实世界中的密码学误用（crypto misuse）检测工具进行了评估，分析了产生误报的主要原因，为后续的研发提供了指导。而且这篇论文似乎是在“呛声”2022年IEEE S&P上的论文Why Crypto-detectors Fail: A Systematic Evaluation of Cryptographic Misuse Detection Techniques（G.O.S.S.I.P 学术论文推荐 2021-07-23），因为那篇论文认为应该降低的是false negative的出现。我们也欢迎读者留言，你们认为是减少漏报重要，还是减少误报更重要？
这篇论文研究的对象包括CryptoGuard（来自2019年CCS论文）, CogniCrypt-SAST（来自2019年的TSE期刊）和CryptoREX（2019年RAID论文）三个工具（因为它们都提供了代码），前两个工具针对Java代码，而后一个工具主要是对嵌入式固件中的密码学误用进行检测。它们分别支持检测的密码学误用类别如下面的表格所示：
由于缺少标准的benchmark（而且这些工具支持检测的误用类别都不太一致），作者只能先去小规模人工评估这些工具的误报情况，然后总结可能的典型误报案例，再大规模测试看看这种现象是否普遍。在这个方法论的支持下，作者给出了非常详细的论述，充满了很多启示，让我们分门别类地阅读。
首先作者介绍了因为静态代码分析技术（特别是数据流分析）中的各种毛病导致的误报。对于CryptoGuard这个依赖于Soot引擎的工具，其分析的准确性也高度受制于Soot的实现完备性。当然，除了引擎的问题，也有一些是CryptoGuard自己的实现问题。在下面的例子中，CryptoGuard会报告一个constant password的警告（第8行代码中，通过pwd解密外部文件的数据，对ks进行初始化），实际上根本不存在，这是为什么？
问题出在CryptoGuard的backward slicing算法的实现，这个算法是在Soot的Jimple IR进行反向追踪。如下图的IR所示，在本例中，CryptoGuard从第11行的$r5开始反向追踪，先追溯到第10行的$r2，然后就忘记了赋值操作会清除掉之前的数据传播！结果把第7行那个对$r2的赋值也算进来了。显然这两个$r2之间并没有什么关系，但是CryptoGuard会建立一条不存在的数据流（从第7行到第11行），然后根据这个constant value assignment来报警。
作者顺便指出，如果Soot的Jimple IR使用的是SSA格式也就是static single assignment（不熟悉的读者可以去翻一下比较新的编译原理的参考资料），CryptoGuard就不会出现这个问题了，显然CryptoGuard对Soot的IR的特性没有吃准，导致了很多误报：
作者还发现，随着Soot的升级，CryptoGuard在基于新版本的Soot引擎进行分析时产生的误报更多，原因非常奇怪。首先，对于原来版本的Soot，CryptoGuard在实现field-sensitive analysis（也就是分析的时候要追踪到某个object的field，而不是把这个object当成一个整体来考察）时有一个bug，对field name进行匹配的正则表达式写错了（漏掉了一个非常常见的情况——在Jimple IR中变量可能以$开头），因此会漏掉很多情况，反而降低了误报。而新版本的Soot实现里面，大幅度减少了用$开头的变量的情况，结果反而导致CryptoGuard标记了更多的对象，产生了更多的误报（这，手动捂脸吧）。。。
作者分析CogniCrypt-SAST的检测结果时，发现它在判定数组是否硬编码时存在一个bug：在判定一个分配的对象是否为常量时（例如一个赋值语句r1 = newarray (char)[]），检查的是右值（right-hand-side value，这里是newarray (char)[]）而不是左值（left-hand-side value，这里是r1），这导致后续不管怎么操作r1，分析工具都匹配不到任何对象，然后就以为任何情况都是常量。例如下面这个非常simple and naive的例子，CogniCrypt-SAST都会报告第3行是常量赋值。。。当然，如果你开发过静态代码分析工具（或者阅读过相关代码，比如Clang Static Analyzer）就会明白这里面的复杂性，我们也不能太苛责相关工具的开发人员。
CryptoREX是基于angr二进制代码分析引擎而设计的，但是它没用到angr的CFG分析还原算法，而是自己实现了一个，这个算法会在backward slicing的时候忽略掉所有的function call语句，但是它却忘记把函数调用的参数也一起忽略了。在下面这个例子中，CryptoREX会忽略掉sub_5A7D4而直接把那个参数也就是4096直接传递给左边的变量，因此报告了一个constant value assignment，这种处理导致了许多误报。
讲完了工具实现的问题，作者还指出，在密码学误用检测方法的分析模型设计上，这些工具也存在一堆问题，比如针对Password-Based Encryption（PBE）的密钥生成，一般认为只要对password进行1000次迭代，生成相关key就可以了，但是CogniCrypt-SAST把这个下界设置成了10000，而CryptoGuard在判定密钥长度的时候，也比标准要求的要更严格：在对于椭圆曲线公钥密码算法（一般只需要256-bit的密钥就够安全了）时要求所有密钥至少要达到512 bit才行，因此产生了许多误报。
同时，在系统对密码算法的实现中，也有一些安全防御措施是当前的检测工具没有考虑的。例如在随机数发生器SecureRandom的实现中，即使开发人员提供了常量的seed，只要在此前已经有一些随机的初始化操作，这个常量的seed并不会覆盖掉原来的seed，只会增加一些熵（当然这里没有增加什么熵，但是也没减少），因此只要看到常量seed就报告问题，并不是那么准确。
还有一些案例是经典的taint analysis教程都会提到的，比如像下面这个隐式控制流的例子，通过控制流传播了1 bit的信息，如果数据流分析没写好，这里就会丢失掉传播的信息，进而报告出SSL/TLS连接缺乏验证的misuse警告。
在论文中提到的一大类误报，来自脱离上下文进行分析的失误。例如经典的“检测ECB模式”这个告警操作，很多时候都出现在一些密码算法库的内部：其实这些都是拿AES-ECB来作为核心进行封装，然后实现更为复杂的模式（例如AES-EAX），但是检测工具不管三七二十一就告警了。而另一个经典的告警——“使用MD5”也是一样，比如在Facebook的代码库里面只是用MD5来当checksum用（针对上传的log），这种地方可能很难说有什么严重的安全攻击（当然这个地方用xxhash是不是更快哈哈哈）。
最后，作者发现，在很多标准中，为了向下兼容（不是所有标准都是由Apple制定的），还是保留了一些弱密码算法。比如在org.minidns.dnssec和org.xbill.dns这两个包里面，为了符合DNSSEC的标准，必须要支持RSASHA1签名验证。另一个例子是对低版本的PDF加密文件格式的支持：需要保留AES/ECB/NOPADDING这个会导致告警的模式。当然，遇到这些情况，如果开发人员既熟悉密码学又熟悉相关标准，肯定知道怎么处理，但是现实中有多少工程师能够做到这两者都烂熟于胸呢？
考察完学术界的工作，作者还顺带检查了一下工业界常用的SpotBugs工具以及它的各种插件（统称为FindSecBugs），结果和前面大差不差。主要的差别在于FindSecBugs没有进行任何数据流分析，因此反而避免了前面出现的一些误报，但是对于真正的需要用数据流分析才能发现的问题（例如constant key），FindSecBugs就没法找到。
论文的附录里面有很多细节（特别是找到三个误用检测工具相关bug的细节），很佩服作者的细心分析和技术功力。最后还提供了Artifact的使用指南，大家有兴趣可以去复现一下！
论文：https://www.ndss-symposium.org/wp-content/uploads/2024-1032-paper.pdf
Artifact：https://github.com/kynehc/crypto-detector-evaluation-artifacts
原文始发于微信公众号（安全研究GoSSIP）：G.O.S.S.I.P 阅读推荐 2024-02-19 密码学误用检测工具的误用？
