Secure Coding Practice in Rust

Transcript

1. Secure Coding Practice in Rust Osuke
2. • Software Engineer at Layerx Inc., a blockchain startup based in Tokyo. • Focusing on development of privacy solutions to blockchain-based systems. ◦ Zero-knowledge proving systems ◦ TEE • Core dev. of Zerochain ◦ https://github.com/LayerXcom/zero-chain Osuke Sudo Twitter: @zoom_zoomzo
3. Rust is “fast” and “safe”?
4. Memory safety • Without garbage collection to avoid overhead. • Without error-prone manual memory allocations and deallocations. • Ownership model ◦ Resources can only have one owner. ◦ let x = vec![1, 2, 3]; : x owns resource vec![1, 2, 3] . ◦ let y = x; : Ownership of resource vec![1, 2, 3] moves to y . ◦ let y = &x; : y borrows ownership of resource vec![1, 2, 3] from x . ◦ Compiler can know variable “lifetime”.
5. Memory safety • Avoiding dangerous memory instructions like… ◦ Data races ◦ Dereferencing a null or dangling raw pointer. ◦ Reading undef (uninitialized) memory • Rust programs must never cause undefined behavior.
6. Rust can be “unsafe” • Rust programs can be unsafe only if a unsafe keyword is used explicitly. • The code inside unsafe blocks can break memory safety. ◦ Dereference a raw pointer ◦ Mutable global items: static mut
7. Rust can be “unsafe” • All FFI functions are assumed to be “unsafe”.
8. What is NOT “unsafe”? Rust provides the memory system and the type system to prevent things like... • Memory leak • Deadlock • Integer overflow • … but these are possible!
9. Memory leak is NOT memory safety • mem::forget • Box::leak • Rc and Arc cycles • mpsc::{Sender, Receiver} cycles
10. Drop • Used to run some code when a value goes out of scope. • The equivalent of a destructor • Used to release memory or external resources (sockets, files, etc.).
11. Memory leak of sensitive data • Compilers optimize for performance, and in doing so they love to "optimize away" unnecessary zeroing calls. • Debuggers or remote machines can access leftover values in memory. • Sensitive data must never be accessible. ◦ private key, password, randomness... • Heartbleed bug in OpenSSL ◦ It leads to the leak of memory contents from the server to the client and vice versa.
12. Zeroize • https://github.com/iqlusioninc/crates/tree/develop/zeroize • Zeroize clears sensitive data in memory. • Providing the operation that zeroing memory cannot be “optimized away” by the compiler. • The clear_on_drop crate is no longer maintained.
13. Zeroize • #[derive(Zeroize)] : automatically calls zeroize() on all members of a struct. • #[zeroize(drop)] : call zeroize() when this item is dropped
14. Zeroize • write_volatile : Performs a volatile write of a memory location with the given value and guaranteed to not be elided or reordered by the compiler. • compiler_fence : Restricts the kinds of memory re-ordering the compiler is allowed to do. • Ordering::SeqCst : No re-ordering of reads and writes across this point is allowed.
15. Timing leaks? • Timing leaks could be occured if there exists a relationship between the secret data and the execution time of your code. • It’s best practice to write code that is “constant-time” to prevent timing leaks. ◦ More precisely, “Secret-independent resource usage” P A S S W O R D A A S S W O R D P A S S W O R D P A S S W O D D
16. Subtle • https://github.com/dalek-cryptography/subtle • Pure-Rust traits and utilities for constant-time cryptographic implementations. ◦ 1. The bitwise operations are constant-time ◦ 2. The operations are not optimized into a branch.
17. Subtle
18. Integer overflow • Integer overflow is considered “safe” in Rust. • cargo run detects integer overflow, but cargo run --release doesn’t. • How we can program integer overflow explicitly?
19. Integer overflow
20. Unsecure PRNGs • Use rand crate ◦ Note; Breaking changes happend between v0.4 and v0.5 • Use rand::rngs::OsRng for strong Cryptographically secure PRNGs. ◦ A random number generator that retrieves randomness from the operating system.
21. Fuzzing • An automated software testing technique that involves providing unexpected or random data as inputs to a program. • In paticular, useful for hash functions, serializers, or parsers.. • Lots of bugs are founded by fuzzing. ◦ ref: https://github.com/rust-fuzz/trophy-case • tools ◦ cargo-fuzz ◦ honggfuzz-rs
22. Tools for secure coding • clippy ◦ A collection of lints to catch common mistakes and improve your Rust code. • cargo-audit ◦ Audit Cargo.lock files for crates with security vulnerabilities reported to the RustSec Advisory Database. • cargo-crev ◦ A cryptographically verifiable code review system for the cargo (Rust) package manager.
23. Thank you!