Microsoft plans to use Rust as a safe alternative to C and C++

Microsoft is exploring the use of the Rust programming language as an alternative to C, C++, and other languages ​​to improve the security of applications.

Since 2004, the Microsoft Security Response Center (MSRC) has classified all reported Microsoft security vulnerabilities. According to the data they provide, about 70% of all Microsoft annual patches are fixed for memory security vulnerabilities.

This high percentage is because Windows and most other Microsoft products are written primarily in C and C++. These two “memory-unsafe” programming languages ​​allow developers to fine-grain control memory addresses and execute code. A vulnerability in the code that manages memory execution can lead to a series of memory security errors that an attacker can use to introduce dangerous and intrusive consequences, such as remote code execution or elevation of privilege. Thus, exploring the use of a memory-safe language such as Rust is put on the agenda, which may become an alternative to creating a more secure Microsoft application.

Rust was originally a research project at Mozilla for rewriting the Firefox browser safer and faster. Recently, the Brave browser replaced the ad-blocking component originally written in C++ with the Rust version. The 2019 StackOverflow Developer Survey shows that Rust has been the “most popular programming language for developers” for four consecutive years. Developers like it because its syntax is simpler and there are fewer application bugs written with Rust, so developers can focus on extending their applications instead of ongoing maintenance.

Gavin Thomas, MSRC’s Chief Security Engineering Manager, recommends that third-party developers should also look at the memory-safe language. He cited some reasons, such as developers spending time and effort learning how to debug memory-related security vulnerabilities in C++ applications. But this is obviously not appropriate. “A developer’s core job is not to worry about security but to do feature work. Rather than investing in more and more tools and training and vulnerability fixes, what about a development language where they can’t introduce memory safety issues into their feature work in the first place? That would help both the feature developers and the security engineers—and the customers,” Thomas asked.