Rust Gets Security, WASI 0.2 Support, Productivity Boost
As the adoption of the Rust programming language continues to rise, new challenges as well as advances have also arisen, including security issues, use with WebAssembly (WASM) and productivity benefits.
This week, the Rust team released Rust 1.77.2 to address a critical vulnerability, identified as CVE-2024-24576. The vulnerability affects the Rust standard library on Windows when invoking batch files using the Command API with untrusted arguments. An attacker could potentially execute arbitrary shell commands by bypassing the argument escaping.
The vulnerability is considered critical for developers using batch files on Windows with untrusted arguments. No other platforms or use cases are affected. However, all Rust versions before 1.77.2 on Windows are affected if the code or its dependencies execute batch files with untrusted arguments.
The issue stems from the complex argument-splitting logic of cmd.exe on Windows, which required the standard library to implement custom escaping for arguments passed to batch files. However, the escaping logic was found to be insufficient, the Rust Security Response Working Group wrote in a security advisory blog post.
As a mitigation, the Rust team improved the robustness of the escaping code and modified the Command API to return an InvalidInput error when it cannot safely escape an argument. The fix is included in Rust 1.77.2.
Rust for WebAssembly
Meanwhile, the Rust team has begun implementing first-class support for WebAssembly System Interface (WASI) 0.2 in the form of a dedicated new target, wrote Yosh Wuyts, a Rust developer advocate at Microsoft, in a post on the Rust Blog.
This is important because Rust continues to be one of the best programming languages for building WebAssembly applications and supporting infrastructure.
Rust 1.78, which will be available on May 2, will introduce new wasm32-wasip1 (tier 2) and wasm32-wasip2 (tier 3) targets. wasm32-wasip1 is an effective rename of the existing wasm32-wasi target, freeing the target name up for an eventual WASI 1.0 release.
“Starting [with] Rust 1.78, users of WASI 0.1 are encouraged to begin migrating to the new wasm32-wasip1 target before the existing wasm32-wasi target is removed in Rust 1.84 (January 5th, 2025),” Wuyts wrote.
Moreover, “After nearly five years of work the WASI 0.2 specification was recently stabilized,” Wuyts noted. “This work builds on WebAssembly Components (think: strongly-typed ABI for Wasm), providing standard interfaces for things like asynchronous IO, networking, and HTTP. This will finally make it possible to write asynchronous networked services on top of WASI, something which wasn’t possible using WASI 0.1.”
Rust Provides Two Times the Productivity of C++
Meanwhile, in a recent talk, Lars Bergstrom, director of engineering at Google, said Google’s developers were twice as productive using Rust as writing C++ code.
Speaking at the Rust Nation UK Conference in late March, Bergstrom said Google was “looking at comparing our rewrites of C++ code into Rust. And in every case, we’ve seen a decrease by more than 2x in the amount of effort required to both build the services in Rust, as well as maintain and update those services written in Rust. And so that’s a really huge thing for us because C++ code is very expensive…”
In February, Google pledged $1 million to the Rust Foundation to improve the interoperability between the C++ and Rust programming languages. The goal of the effort is to get organizations to slowly migrate C++ code to Rust, according to The Rust Foundation.
“While Rust may not be suitable for all product applications, prioritizing seamless interoperability with C++ will accelerate wider community adoption, thereby aligning with the industry goals of improving memory safety,” Bergstrom wrote in a blog post. In addition to being a director of engineering at Google, Bergstrom is both the Google director for the Android platform tools and libraries as well as the chair of the Rust Foundation Board.
Rust and Memory Safety
Bergstrom said the industry has grown aware of the challenges of using non-memory-safe languages, including warnings from the White House.
“Now, I do want to admit unsafe code, we need to do more about it,” he said. “But I worry about unsafe code in the same way that my Java teams worry about JNI [Java Native Interface] code, in the same way, that my teams who are writing web services worry about the virtual machine and runtime — we always need to be improving the quality of the entire software stack…”
In February, the White House Office of the National Cyber Director (ONCD) issued a recommendation that software development organizations begin to use memory-safe languages such as Rust for application and systems development, citing Rust as “one example of a memory-safe programming language.”
Busting Rust Myths
Last year, Bergstrom and Kathy Brennan, a low-level Operating Systems Sr. User Experience Researcher, wrote a blog post debunking and confirming many of the common myths about Rust based on surveys of Google’s Rust developers — which roughly aligned with his talk at the Rust Nation UK event.
One thing the post confirmed is that Rust enables developers to deliver high-quality code.
“Android’s experience with Rust has been excellent. My team built the first major component keystore which is a medium-sized component with significant concurrency,” Bergstrom said in his talk. “We’re now three years in and it has been basically flawless. For those of you who haven’t worked in production commercial software, the words ‘basically flawless’ and systems code do not usually appear in the same sentence.”
He added that more than half of the developers surveyed found Rust code easier to review compared to code in other languages, and 85% felt more confident in the correctness of their team’s Rust code compared to code in other languages.
Bergstrom also noted that Rust is not difficult to learn — unlike its reputation as being hard.
He said surveys of Google developers show that it takes about two months for them to become sufficiently productive in Rust, similar to the time it takes for Java developers to become productive in Kotlin — which is another effort Google is undergoing.
“We have a similar migration going on in the Java ecosystem where we’re moving people from Java to Kotlin,” Bergstrom said. “And the number that we use at Google to reflect about how long it takes us to take a Java developer and get them contributing to Kotlin is eight weeks.”
Moreover, Bergstrom noted that developers typically feel as productive in Rust as they were in their previous languages –C++, Java, Python, Go — within four months.
