https://trailofbits.github.io/testing-handbook-preview/pr-preview/pr-128/docs/languages/rust/Recent content in Rust on Testing HandbookHugoen-ushttps://trailofbits.github.io/testing-handbook-preview/pr-preview/pr-128/docs/languages/rust/lang-rust-security-overview/Mon, 01 Jan 0001 00:00:00 +0000https://trailofbits.github.io/testing-handbook-preview/pr-preview/pr-128/docs/languages/rust/lang-rust-security-overview/Rust security overview # Safety and security # The Rust compiler guarantees the memory safety of Rust programs: no undefined behavior or data race will happen during runtime, no matter the inputs. Therefore, when security-testing Rust programs, it’s important to understand what is and what is not considered undefined behavior (UB). There is no sense in looking for double-free bugs in (safe) Rust, right? For the guarantees made by the Rust compiler, see the “Behavior considered undefined” Rust Reference page.https://trailofbits.github.io/testing-handbook-preview/pr-preview/pr-128/docs/languages/rust/lang-rust-dynamic-analysis/Mon, 01 Jan 0001 00:00:00 +0000https://trailofbits.github.io/testing-handbook-preview/pr-preview/pr-128/docs/languages/rust/lang-rust-dynamic-analysis/Rust dynamic analysis # There are two categories of dynamic analysis: fuzz testing and “standard” testing, like unit and functional testing. In this chapter, we will focus on standard testing. This is the basic level of testing that every project should have implemented. While basic, standard testing can be built up with a lot of security-wise improvements. To read about Rust fuzzing, see the Rust fuzzing chapter of this handbook.https://trailofbits.github.io/testing-handbook-preview/pr-preview/pr-128/docs/languages/rust/lang-rust-static-analysis/Mon, 01 Jan 0001 00:00:00 +0000https://trailofbits.github.io/testing-handbook-preview/pr-preview/pr-128/docs/languages/rust/lang-rust-static-analysis/Rust static analysis # Static analysis involves analyzing source code without executing it. Clippy # Clippy is the fundamental linter. Just use it. Clippy lints are categorized into groups and levels. Groups categorize lints by the types of issues they detect. Levels indicate what to do when a lint finds an issue: Allow: Ignore the issue Warn: Print a message to stdout Deny: Return an error code (useful in CI pipelines) Clippy is a wrapper over the rustc compiler, so when Clippy is run, it executes its own set of lints in addition to rustc’s.https://trailofbits.github.io/testing-handbook-preview/pr-preview/pr-128/docs/languages/rust/lang-rust-gotchas-and-footguns/Mon, 01 Jan 0001 00:00:00 +0000https://trailofbits.github.io/testing-handbook-preview/pr-preview/pr-128/docs/languages/rust/lang-rust-gotchas-and-footguns/Rust gotchas and footguns # This section provides a checklist that can be used during manual Rust code reviews. The list represents common issues we have encountered during our audits. It is not comprehensive, but it is a good starting point to quickly bootstrap an audit. For safe code # Check string comparisons. Often partial-match (starts_with, ends_with, contains) is used instead of equality. Case (in)sensitivity of comparisons often results in issues.https://trailofbits.github.io/testing-handbook-preview/pr-preview/pr-128/docs/languages/rust/lang-rust-memory-zeroization/Mon, 01 Jan 0001 00:00:00 +0000https://trailofbits.github.io/testing-handbook-preview/pr-preview/pr-128/docs/languages/rust/lang-rust-memory-zeroization/Rust memory zeroization # Zeroization in the presence of optimizing compilers is difficult. In Rust, it is particularly tricky because of the constraints the compiler imposes on memory management. The compiler can infer significant information about aliasing information that allows unexpected copies of secret data to appear on the stack. For example, consider the pitfall described in the blog post “A pitfall of Rust’s move/copy/drop semantics and zeroing data”.https://trailofbits.github.io/testing-handbook-preview/pr-preview/pr-128/docs/languages/rust/lang-rust-model-checking/Mon, 01 Jan 0001 00:00:00 +0000https://trailofbits.github.io/testing-handbook-preview/pr-preview/pr-128/docs/languages/rust/lang-rust-model-checking/Rust model checking # Model checking means verifying that a program works correctly for all possible inputs. Instead of testing with a single value (like with unit testing) or with a set of values (like with property testing), we check all possible values—and hope that smart algorithms will make it possible to finish testing in a reasonable time. Prusti # Prusti is based on Viper, a framework for building verification tools.https://trailofbits.github.io/testing-handbook-preview/pr-preview/pr-128/docs/languages/rust/lang-rust-specialized-testing/Mon, 01 Jan 0001 00:00:00 +0000https://trailofbits.github.io/testing-handbook-preview/pr-preview/pr-128/docs/languages/rust/lang-rust-specialized-testing/ Rust specialized testing # Concurrency testing # Shuttle Unsound, but scalable Works analogously to property testing Loom Sound, but slow Works analogously to model checkers Fault injections # MadSim Replaces the tokio and tonic crates with simulated versions Injects faults and increases randomness fail-rs Needs you to manually add fail_point! macros into the codehttps://trailofbits.github.io/testing-handbook-preview/pr-preview/pr-128/docs/languages/rust/lang-rust-supply-chain-analysis/Mon, 01 Jan 0001 00:00:00 +0000https://trailofbits.github.io/testing-handbook-preview/pr-preview/pr-128/docs/languages/rust/lang-rust-supply-chain-analysis/Rust supply chain analysis # Vetting # The tools in this section are more for “understanding” than “checking.” That is, running them does not produce bug reports, but can help you assess the maturity and security of dependencies. The tools below are quantitative rather than qualitative; you will need to perform manual, in-depth review of the outputs to extract any solid evidence about the maturity. cargo-supply-chain # The tool reveals who you are implicitly trusting via dependencies.