Secure Coding Practice in Rust

Transcript

1. 1.

   Secure Coding Practice in Rust Osuke

2. 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. 3.

   Rust is “fast” and “safe”?

4. 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. 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. 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. 7.

   Rust can be “unsafe” • All FFI functions are assumed

   to be “unsafe”.
8. 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. 9.

   Memory leak is NOT memory safety • mem::forget • Box::leak

   • Rc and Arc cycles • mpsc::{Sender, Receiver} cycles
10. 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. 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. 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. 13.

    Zeroize • #[derive(Zeroize)] : automatically calls zeroize() on all members

    of a struct. • #[zeroize(drop)] : call zeroize() when this item is dropped
14. 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. 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. 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. 17.

    Subtle

18. 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. 19.

    Integer overflow

20. 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. 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. 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. 23.

    Thank you!