Amazon Web Services (AWS) has launched a competition to test the security of the Rust standard library. Individual challenges verify different areas of the Rust libraries.
Advertisement
The Rust Foundation, which takes care of the development of the programming language, supports the competition.
Rust is particularly popular because of its memory safety concepts. The specifications prevent specific memory errors that are responsible for most vulnerabilities in software.
Unsafe corrosion does not have to be unsafe, but it can be.
However, Rust reaches its limits in low-level programming, for example for direct interaction with the operating system. exists as a way keyword unsafeWhich, among other things, removes the restriction on dereferencing raw pointers.
Unsafe Rust does not mean that the code is unsafe, but rather that some memory safety concepts do not work. Dereferencing a raw pointer can lead to undefined behavior if the code does not check the pointer adequately beforehand.
Also like unsafe Rust provides so-called safe abstractions: a function is considered safe even if it is unsafeCode included. The function itself is responsible for ensuring that the internal unsafeThe block does not cause undefined behavior. A Detailed example can be found in the Rust documentation,
there is a lot to do
According to AWS, Rust’s standard library contains about 35,000 functions, of which 7500 are unsafe are marked. The other 3,000 are protected intangibles. For Rust’s core library of about 21,000 functions, AWS’s count is 7000. unsafe Marked and additional 1700 safe essences.
Over the past three years, 57 Rust standard library security issues have been launched and there have been 20 CVE (Common Vulnerabilities and Exposures) listings.
The competition launched by AWS relies on crowdsourcing to improve the security of the standard library.
Rewards for completing challenges
A series of challenges are used to test different areas of the library. For successfully completed challenges, AWS pays financial rewards, the amount of which is not specified in the blog post.
As an example of a challenge, the article cites “Challenge 10: Memory Safety of StringsOn the safe abstraction of insert-work of std::string::String to check:
pub fn insert(&mut self, idx: usize, ch: char) {
assert!(self.is_char_boundary(idx));
let mut bits = (0; 4);
let bits = ch.encode_utf8(&mut bits).as_bytes();
unsafe {
self.insert_bytes(idx, bits);
}
}It is important to implement IM unsafe– block used functions insert_bytes verify:
unsafe fn insert_bytes(&mut self, idx: usize, bytes: &(u8)) {
let len = self.len();
let amt = bytes.len();
self.vec.reserve(amt);
unsafe {
ptr::copy(self.vec.as_ptr().add(idx), self.vec.as_mut_ptr().add(idx + amt), len - idx);
ptr::copy_nonoverlapping(bytes.as_ptr(), self.vec.as_mut_ptr().add(idx), amt);
self.vec.set_len(len + amt);
}
}Each challenge has a list of criteria that must be successfully tested to ensure safety. In its blog post, AWS lists some tools that are suitable for verifying functions in different ways.
a rust fork for testing
To compete, AWS has Created a GitHub repositoryWhich has both challenges and forks of the standard library. This fork obviously does not serve as a substitute for the official Rust release, but only to complement the challenges.
More details can be found AWS Blog and this Rust Foundation announcement Removal
(rme)
