[论文解读] Memory-Safety Challenge Considered Solved? An In-Depth Study with All Rust CVEs

Hui Xu, Zhuangbin Chen+3 more|arXiv (Cornell University)|Mar 6, 2020

Security and Verification in Computing参考文献 36被引用 11

一句话总结

本文通过分析186个涉及内存安全的现实世界CVE，研究Rust在防止内存安全漏洞方面的有效性。研究发现，所有此类漏洞均需使用unsafe代码，证实了Rust的核心承诺；然而，安全API中存在细微的soundness问题——尤其在所有权、函数和泛型方面——仍构成持续挑战，因此提出更安全的编程实践和工具扩展建议。

ABSTRACT

Rust is an emerging programing language that aims at preventing memory-safety bugs without sacrificing much efficiency. The claimed property is very attractive to developers, and many projects start using the language. However, can Rust achieve the memory-safety promise? This paper studies the question by surveying 186 real-world bug reports collected from several origins which contain all existing Rust CVEs (common vulnerability and exposures) of memory-safety issues by 2020-12-31. We manually analyze each bug and extract their culprit patterns. Our analysis result shows that Rust can keep its promise that all memory-safety bugs require unsafe code, and many memory-safety bugs in our dataset are mild soundness issues that only leave a possibility to write memory-safety bugs without unsafe code. Furthermore, we summarize three typical categories of memory-safety bugs, including automatic memory reclaim, unsound function, and unsound generic or trait. While automatic memory claim bugs are related to the side effect of Rust newly-adopted ownership-based resource management scheme, unsound function reveals the essential challenge of Rust development for avoiding unsound code, and unsound generic or trait intensifies the risk of introducing unsoundness. Based on these findings, we propose two promising directions towards improving the security of Rust development, including several best practices of using specific APIs and methods to detect particular bugs involving unsafe code. Our work intends to raise more discussions regarding the memory-safety issues of Rust and facilitate the maturity of the language.

研究动机与目标

• 评估Rust是否如其设计者所宣称的那样，在真实系统中真正防止了内存安全漏洞。
• 识别并分类Rust程序中除unsafe代码外导致内存安全漏洞的根本原因。
• 理解安全API在引入细微soundness问题方面的作用，这些问题可能导致内存安全违规。
• 为开发者和工具构建者提供可操作的建议，以提升Rust的安全性。
• 在截至2020年底的已知Rust CVE中，扩展先前工作，分析一个全面的数据集。

提出的方法

• 从多个来源（包括Advisory-DB、Trophy Case和GitHub项目）收集了186个内存安全CVE的数据集，涵盖截至2020年12月所有已知的具有内存安全问题的Rust CVE。
• 手动分析每个漏洞，分类其后果（如use-after-free、缓冲区溢出）并识别根本原因模式。
• 采用混合方法：使用标准内存安全类别对漏洞后果进行自上而下的标注，并对相似的罪魁祸首模式进行自下而上的分组。
• 将漏洞分为三类主要类型：自动内存回收、不sound的函数，以及不sound的泛型或trait使用。
• 提出安全API使用的最佳实践，并建议扩展静态分析工具以检测unsafe代码中不安全的模式，特别是与所有权和drop语义相关的问题。
• 与先前工作（如Qin et al., 2020）进行比较，突出本研究的创新贡献，特别是在泛型和基于trait的unsoundness分析方面。

实验结果

研究问题

• RQ1 现实世界中Rust的内存安全漏洞在多大程度上需要unsafe代码，从而证实Rust的内存安全承诺？
• RQ2 当不涉及显式unsafe块时，Rust内存安全漏洞的主要模式和根本原因是什么？
• RQ3 Rust的所有权和借用系统，特别是自动drop和栈展开机制，如何导致意外的内存安全问题？
• RQ4 开发者在编写sound的泛型或trait代码时面临哪些主要挑战，这些挑战如何导致unsoundness？
• RQ5 可以为开发者和工具构建者提供哪些实际建议，以提升Rust程序的安全性？

主要发现

• 数据集中所有186个内存安全漏洞均需使用unsafe代码，证实当使用安全代码时，Rust成功实现了其内存安全承诺。
• 许多内存安全问题并非关键利用，而是安全API中的轻微soundness问题，例如不正确的drop实现或不sound的trait边界。
• 自动内存回收——由Rust的所有权系统和drop语义触发——会导致use-after-free、double-free和无效指针问题，尤其在栈展开期间更为明显。
• 不sound的函数是Rust开发中的核心挑战，因为即使没有unsafe块，也可能引入未定义行为，通常源于错误的类型级别推理。
• 不sound的泛型或trait使用是一个日益严重的问题，特别是在泛型约束或trait实现违反内存安全时，且是更复杂、更隐蔽的错误来源。
• 本研究识别出特定的API模式和编码实践，这些会增加unsoundness的风险，从而提出具体的更安全Rust开发建议。