G.O.S.S.I.P 阅读推荐 2024-02-19 密码学误用检测工具的误用?

密码学 5个月前 admin
20 0 0

每年最早召开的安全会议之一的NDSS即将在本月底迎来2024的版本,在今年的论文中,有一篇关注密码学误用的研究论文Towards Precise Reporting of Cryptographic Misuses,我们今天要推荐给大家。这篇论文也通过了NDSS的Artifact Evaluation,方便大家验证结果。

G.O.S.S.I.P 阅读推荐 2024-02-19 密码学误用检测工具的误用?

在软件工程研究社区,大家对于代码静态分析工具的态度似乎是“宁可错杀一千,不可错过一个”。也就是说,最好不要有漏报(false negative)。但是安全研究社区(以及现实生活中的开发者)觉得太多的误报(false positive)反而会让人觉得暴躁,进而忽视一切的警告。今天这篇论文作者也表达了类似的观点,他们针对现实世界中的密码学误用(crypto misuse)检测工具进行了评估,分析了产生误报的主要原因,为后续的研发提供了指导。而且这篇论文似乎是在“呛声”2022年IEEE S&P上的论文Why Crypto-detectors Fail: A Systematic Evaluation of Cryptographic Misuse Detection TechniquesG.O.S.S.I.P 学术论文推荐 2021-07-23),因为那篇论文认为应该降低的是false negative的出现。我们也欢迎读者留言,你们认为是减少漏报重要,还是减少误报更重要?

这篇论文研究的对象包括CryptoGuard(来自2019年CCS论文), CogniCrypt-SAST(来自2019年的TSE期刊)和CryptoREX(2019年RAID论文)三个工具(因为它们都提供了代码),前两个工具针对Java代码,而后一个工具主要是对嵌入式固件中的密码学误用进行检测。它们分别支持检测的密码学误用类别如下面的表格所示:

G.O.S.S.I.P 阅读推荐 2024-02-19 密码学误用检测工具的误用?

G.O.S.S.I.P 阅读推荐 2024-02-19 密码学误用检测工具的误用?

由于缺少标准的benchmark(而且这些工具支持检测的误用类别都不太一致),作者只能先去小规模人工评估这些工具的误报情况,然后总结可能的典型误报案例,再大规模测试看看这种现象是否普遍。在这个方法论的支持下,作者给出了非常详细的论述,充满了很多启示,让我们分门别类地阅读。

首先作者介绍了因为静态代码分析技术(特别是数据流分析)中的各种毛病导致的误报。对于CryptoGuard这个依赖于Soot引擎的工具,其分析的准确性也高度受制于Soot的实现完备性。当然,除了引擎的问题,也有一些是CryptoGuard自己的实现问题。在下面的例子中,CryptoGuard会报告一个constant password的警告(第8行代码中,通过pwd解密外部文件的数据,对ks进行初始化),实际上根本不存在,这是为什么?

G.O.S.S.I.P 阅读推荐 2024-02-19 密码学误用检测工具的误用?

问题出在CryptoGuard的backward slicing算法的实现,这个算法是在Soot的Jimple IR进行反向追踪。如下图的IR所示,在本例中,CryptoGuard从第11行的$r5开始反向追踪,先追溯到第10行的$r2,然后就忘记了赋值操作会清除掉之前的数据传播!结果把第7行那个对$r2的赋值也算进来了。显然这两个$r2之间并没有什么关系,但是CryptoGuard会建立一条不存在的数据流(从第7行到第11行),然后根据这个constant value assignment来报警。

G.O.S.S.I.P 阅读推荐 2024-02-19 密码学误用检测工具的误用?

作者顺便指出,如果Soot的Jimple IR使用的是SSA格式也就是static single assignment(不熟悉的读者可以去翻一下比较新的编译原理的参考资料),CryptoGuard就不会出现这个问题了,显然CryptoGuard对Soot的IR的特性没有吃准,导致了很多误报:

G.O.S.S.I.P 阅读推荐 2024-02-19 密码学误用检测工具的误用?

作者还发现,随着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)就会明白这里面的复杂性,我们也不能太苛责相关工具的开发人员。

G.O.S.S.I.P 阅读推荐 2024-02-19 密码学误用检测工具的误用?

CryptoREX是基于angr二进制代码分析引擎而设计的,但是它没用到angr的CFG分析还原算法,而是自己实现了一个,这个算法会在backward slicing的时候忽略掉所有的function call语句,但是它却忘记把函数调用的参数也一起忽略了。在下面这个例子中,CryptoREX会忽略掉sub_5A7D4而直接把那个参数也就是4096直接传递给左边的变量,因此报告了一个constant value assignment,这种处理导致了许多误报。

G.O.S.S.I.P 阅读推荐 2024-02-19 密码学误用检测工具的误用?

讲完了工具实现的问题,作者还指出,在密码学误用检测方法的分析模型设计上,这些工具也存在一堆问题,比如针对Password-Based Encryption(PBE)的密钥生成,一般认为只要对password进行1000次迭代,生成相关key就可以了,但是CogniCrypt-SAST把这个下界设置成了10000,而CryptoGuard在判定密钥长度的时候,也比标准要求的要更严格:在对于椭圆曲线公钥密码算法(一般只需要256-bit的密钥就够安全了)时要求所有密钥至少要达到512 bit才行,因此产生了许多误报。

同时,在系统对密码算法的实现中,也有一些安全防御措施是当前的检测工具没有考虑的。例如在随机数发生器SecureRandom的实现中,即使开发人员提供了常量的seed,只要在此前已经有一些随机的初始化操作,这个常量的seed并不会覆盖掉原来的seed,只会增加一些熵(当然这里没有增加什么熵,但是也没减少),因此只要看到常量seed就报告问题,并不是那么准确。

G.O.S.S.I.P 阅读推荐 2024-02-19 密码学误用检测工具的误用?

还有一些案例是经典的taint analysis教程都会提到的,比如像下面这个隐式控制流的例子,通过控制流传播了1 bit的信息,如果数据流分析没写好,这里就会丢失掉传播的信息,进而报告出SSL/TLS连接缺乏验证的misuse警告。

G.O.S.S.I.P 阅读推荐 2024-02-19 密码学误用检测工具的误用?

在论文中提到的一大类误报,来自脱离上下文进行分析的失误。例如经典的“检测ECB模式”这个告警操作,很多时候都出现在一些密码算法库的内部:其实这些都是拿AES-ECB来作为核心进行封装,然后实现更为复杂的模式(例如AES-EAX),但是检测工具不管三七二十一就告警了。而另一个经典的告警——“使用MD5”也是一样,比如在Facebook的代码库里面只是用MD5来当checksum用(针对上传的log),这种地方可能很难说有什么严重的安全攻击(当然这个地方用xxhash是不是更快哈哈哈)。

最后,作者发现,在很多标准中,为了向下兼容(不是所有标准都是由Apple制定的),还是保留了一些弱密码算法。比如在org.minidns.dnssecorg.xbill.dns这两个包里面,为了符合DNSSEC的标准,必须要支持RSASHA1签名验证。另一个例子是对低版本的PDF加密文件格式的支持:需要保留AES/ECB/NOPADDING这个会导致告警的模式。当然,遇到这些情况,如果开发人员既熟悉密码学又熟悉相关标准,肯定知道怎么处理,但是现实中有多少工程师能够做到这两者都烂熟于胸呢?

考察完学术界的工作,作者还顺带检查了一下工业界常用的SpotBugs工具以及它的各种插件(统称为FindSecBugs),结果和前面大差不差。主要的差别在于FindSecBugs没有进行任何数据流分析,因此反而避免了前面出现的一些误报,但是对于真正的需要用数据流分析才能发现的问题(例如constant key),FindSecBugs就没法找到。

G.O.S.S.I.P 阅读推荐 2024-02-19 密码学误用检测工具的误用?

论文的附录里面有很多细节(特别是找到三个误用检测工具相关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 密码学误用检测工具的误用?

版权声明:admin 发表于 2024年2月19日 下午8:32。
转载请注明:G.O.S.S.I.P 阅读推荐 2024-02-19 密码学误用检测工具的误用? | CTF导航

相关文章