Skip to content
The methodOpen data
Back to the collection

Memory-Safety Challenge Considered Solved? An In-Depth Study with All Rust CVEs

Hui Xu, Zhuangbin Chen, Mingshen Sun, Yangfan Zhou, Michael Lyu

2020 · arXiv

Security & cryptography
Read the paper
HN score
0
Mentions
6
Readers
3
Months
6
What’s in a score?

From the 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.

Metadata: arXiv. Abstracts retain their original authors’ rights.

In the conversation

Original HN comments, with labels from simple text rules. A label describes the whole comment and may miss context or irony. Read the discussion to make up your own mind. About the labels

6 selected excerpts · 6 total mentions

timschmidt
Neutral mention · rule
Microsoft: 70% of all security bugs are memory safety issues: https://www.zdnet.com/article/microsoft-70-percent-of-all-se... Chrome: 70% of all security bugs are memory safety issues: https://www.zdnet.com/article/chrome-70-of-all-security-bugs... "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…
Read the full comment
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...": https://arxiv.org/abs/2003.03296 Seems persuasive to me.
Original comment Tell HN: When Firefox jumps the shark, the call to action is Ladybird
Arch-TK
Neutral mention · rule
Here is a good summary of how Ada deals with safety in the context of memory management: https://news.ycombinator.com/item?id=14216128 It's not rust but at the same time I think rust has sacrificed general safety in favor of memory safety which has produced a tendency towards a false sense of security. After all, it seems rust still has memory safety issues despite the borrow checker: https://arxiv.org/pdf/2003.03296.pdf
Original comment Mitigating Memory Safety Issues in Open Source Software
rvz
Neutral mention · rule
Yet once the Chromium team goes down that Rust to C++ FFI route, they will encounter the same old bugs outlined in this paper. [0] They might as well fork Servo and create their own engine from that, but even that is still a prototype worked on for years with zero C++ at least. It's too early to see how the Chromium team will begin to work on this given it's only a plan, but maybe the unsafety and security issues are enough motivation to actually use Rust to C++ interop or a rewrite. But once again, this has been tried by some other projects and by just looking at the effort of a rewrite, they later concluded that it is not worth it. [1] [2] Even better, just improve…
Read the full comment
Servo instead. But I guess they would rather create their own fork, just like they did with WebKit. [0] https://arxiv.org/pdf/2003.03296.pdf [1] https://blogs.dust3d.org/2019/03/13/why-i-rewrote-the-mesh-g... [2] http://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-i...
Original comment Rust and C++ Interoperability in Chrome
timschmidt
Neutral mention · rule
https://arxiv.org/abs/2003.03296 "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…
Read the full comment
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."
Original comment Fish (shell) porting to Rust from C++
rvz
Neutral mention · rule
Don't let your feelings get in the way of your valid argument about C++. The Linux kernel will eventually going use the FFI route from Rust and C someday, but it is no safer in both safe Rust and unsafe Rust according to this memory saftey assessment study that has Rust CVEs [0] [0] https://arxiv.org/pdf/2003.03296.pdf
Original comment Linux kernel in-tree Rust support
rvz
Neutral mention · rule
That's if you use 'Safe Rust', then the safety guarantees hold true. However, the risks increase as soon as you start using unsafe{} or import a crate that also has unsafe{} code which is why I like using cargo-geiger on my projects to see the unsafe{} uses in my code and dependencies [0]. Use unsafe{} at your own risk. [1] [0] https://github.com/rust-secure-code/cargo-geiger [1] https://arxiv.org/abs/2003.03296
Original comment Microsoft: Rust Is the Industry’s ‘Best Chance’ at Safe Systems Programming

Keep following the thread.

More in Security & cryptography

More from the same topics.

2014arXiv

Explaining and Harnessing Adversarial Examples

Ian J. Goodfellow, Jonathon Shlens, Christian Szegedy

Several machine learning models, including neural networks, consistently misclassify adversarial examples---inputs formed by applying small but intentionally worst-case perturbations to examples from the dataset, such that the perturbed input results in the model outputting an incorrect answer with high confidence.

Machine learningSecurity & cryptography
16 mentions11 months
1.5HN score