Just as Microsoft is trying to get consumers to upgrade to the latest Windows 11 as much as possible, U.S. security agencies are working hard to replace languages like C and C++ that can't automatically prevent memory errors with more secure languages like Rust.
Image Creator from Microsoft Designer
The U.S. security establishment issued another 22-page report "pointing fingers" at open source software
Recently, the U.S. Cybersecurity Division (CISA), together with the Federal Bureau of Investigation (FBI), the Australian Signals Bureau (ASD), the Australian Cybersecurity Centre (ACSC) and the Canadian Cyber Security Centre (CCCS), released a 22-page survey report - "Exploring Memory Safety in Key Open Source Projects", summarizing their findings on the use of memory-insecure code in OSS.
Using GitHub's code hosting platform and OpenSSF (Open Source Security Foundation) as research platforms, CISA analyzed 172 key open source projects around the world, including mainstream browsers, operating systems, databases, and framework projects such as Chromium, Linux, MySQL Server, TensorFlow, JDK, Node, KVM, and GCC.
At the same time, the memory insecure languages used by CISA and other institutions are defined as follows, covering memory-insecure programming languages such as Assembly, C, C++, and Cython.
According to the survey, it has come to the following conclusions:
- 52% of the 172 projects were written in C, C++, and other so-called "memory-unsafe" languages.
- 55% of the total line of code (LoC) of all projects is written in memory-insecure language.
- Some of the most popular projects are largely written in memory-insecure programming languages. Each of the top 10 projects by total number of LoCs uses more than 26% of memory-unsafe LoCs. The median percentage of those ten projects using memory-unsafe language was 62.5 percent, and four of the ten projects had a percentage of more than 94 percent.
- A dependency analysis of three projects written in a memory-safe language showed that each project depended on other components written in a memory-unsafe language.
Specifically, according to the survey data, there are a total of 26,023 KLoC (1,000 lines of code) in Linux projects, and about 95% of the lines of code are memory insecure; For MySQL Server, it's 84%; For TensorFlow, that number is 64%; For Zephyr, that number is 84%; For Chromium, that number is 51%.
On average, 26% of the total lines of code in the 10 largest open source projects are memory-insecure code. Even projects written in memory-safe languages are at risk by relying on insecure components.
At the same time, the report said, "We determined that most of the critical open source projects analyzed, even those written in memory-safe languages, may contain memory-safety vulnerabilities." This can be caused by projects that directly use a memory-unsafe language or an external dependency that uses a memory-unsafe language. In addition, disabling low-level feature requirements for memory safety can create memory safety vulnerabilities in code written in other memory safety languages. These limitations underscore the need to continue to use memory-safe programming languages, secure coding practices, and secure testing in a serious manner."
Several reports have been published calling for the deprecation of memory-insecure programming languages such as C/C++
In fact, in recent years, the industry has become increasingly concerned about memory safety. According to a Consumer Report (https://advocacy.consumerreports.org/wp-content/uploads/2023/01/Memory-Safety-Convening-Report.pdf) published in October 2022 by the security organization Security Planner, "Approximately 60%-70% of browser and kernel vulnerabilities – and security vulnerabilities found in the C/C++ codebase due to memory insecurity. The report also cites an interesting discussion about the security costs and benefits of using memory-safe languages instead of memory-unsafe languages.
Since then, the use of a more secure in-memory language has become the main direction of guidance for many government agencies in the United States, which is why they have issued multiple documents calling for projects to migrate to more secure programming languages:
- In November 2022, the U.S. National Security Agency (NSA) issued guidance on protecting software developers and operators from memory safety issues, encouraging organizations to switch from C/C++ to memory-safe languages such as C#, Rust, Go, Java, Ruby, and Swift, primarily because it helps software developers and users prevent and mitigate software memory safety issues, which account for a significant portion of exploitable vulnerabilities;
- The 2023 National Cybersecurity Strategy, published in March 2023, and the corresponding implementation plan released in July 2023, both discuss investing in memory safety and working with the open source community. Initiative 4.1.2 of the National Cybersecurity Strategy Implementation Plan, "Promoting the Adoption of Open Source Software Security and Memory Safe Programming Languages", directs the establishment of the "Open Source Software Security Initiative (OS3I) to promote the adoption of memory security programming languages and open source software security." Initiative 4.2.1 in the same document, "Accelerating the Maturity, Adoption, and Security of Memory-Safe Programming Languages," also calls for investment in memory-safe programming languages and seeks the participation of the newly formed OS3I.
- In December 2023, the U.S. Cybersecurity and Infrastructure Agency (CISA) also began publishing a 23-page Memory Safety Roadmap Guide in conjunction with the NSA, the Federal Bureau of Investigation (FBI), and cybersecurity agencies in Australia, Canada, the United Kingdom, and New Zealand, which states that memory safety vulnerabilities are one of the most common types of software vulnerabilities and impose significant costs associated with remediation, timely response, and other efforts for software manufacturers and consumers. Software manufacturers are advised to create a memory safety roadmap that includes a plan to address memory safety in external dependencies, often including open source software.
- In February 2024, the White House Office of the Director of National Cyber (ONCD) issued a 19-page PDF report titled "Back to the Basics: The Road to Secure Software," calling for "C, C++ is not secure, new applications should be used when they are developed, and old applications should be migrated."
Nowadays, the report released by CISA and other international security organizations directly reveals the number of lines of code written in the insecure memory language used in some mainstream open source projects, and it also follows the above strategic route, hoping to attract the attention of developers and enterprises to effectively avoid memory safety errors.
Major technology companies have already started to "rewrite", "migrate" and other actions
The report also reaffirms that memory-insecure programming languages like C and C++ allow programmers to have more direct control over memory-related functions in their code, which often leads to very common application security issues such as buffer overflows, use of uninitialized memory, type confusion, and use-after-release vulnerabilities. These defects account for a large percentage of all vulnerabilities in modern application software.
In contrast, memory-safe languages (most commonly Rust, Python, Java, and Go) provide protections such as built-in runtime and compile-time checks to mitigate common memory-related errors.
In recent years, under the guidance of policies, many large manufacturers and projects have indeed begun to use memory-safe programming languages:
- In 2021, the Rust Foundation was founded with the support of founding members such as AWS, Huawei, Google, Microsoft, and Mozilla.
- Linux is starting to incorporate Rust code in December 2022. Linus Torvalds, the father of Linux, revealed at Open Source Summit Japan 2023 last December, "Rust has been growing, but we haven't really relied on any part of the kernel yet. For me, Rust is one of those things that makes sense technically, but for me personally, it's more important that we as kernels and developers can't stand still. ”
- Still, Torvalds continued, "Rust hasn't really been the next great thing yet. But I think in the next year, we're going to start integrating drivers, and even some of the major subsystems are going to start using Rust actively. Therefore, it will take years for it to become an important part of the kernel. But it will definitely become part of the kernel. ”
- The Prossimo project, initiated by the Internet Security Research Group (ISRG), aims to improve the Internet's sensitive software infrastructure, represented by the Linux kernel, by using a language with memory-safe properties to address memory safety issues in C and C++ code. Developers involved in the Prossimo project have been rewriting key open-source libraries in Rust to reduce the risk of memory flaws in legacy code. Just this week, Let's Encrypt said it had deployed ntpd-rs, the Network Time Protocol (NTP) daemon that Prossimo rewrote in Rust.
At the same time, along with this trend, both Google and Microsoft are moving towards memory-safe languages, initially for new projects and more recently for application rewrites.
Not long ago, Google's Director of Engineering, Lars Bergstrom, shared Google's experience migrating projects written in Go or C++ to Rust at the Rust Nation UK conference in London. "Development teams in Rust are about twice as productive as teams in C++," he says.
For another big tech company, Microsoft, after its director of Windows OS security, David "dwizzle" Weston, revealed that Microsoft is rewriting the core Windows library in the Rust programming language.
There is still a long way to go
However, given the complexity and cost of rewriting the codebase entirely in memory-safe languages, it is unrealistic to expect to achieve large-scale changes in the industry through policy alone.
Not to mention that in response to the challenges of memory-safe programming languages, controversial programming languages such as the C++ community are also experimenting with C++ configuration files that provide security guarantees at compile time.
In response to this, CISA also pointed out in the report that there is still a lot of work to be done.
"Where performance and resource constraints are placed, we expect memory-insecure languages to continue to be used, including operating system kernels and drivers, cryptography and networking, especially for embedded applications," the CISA report states, "and at the same time, developers may disable memory-safe features even when using memory-safe languages." In its response to the 'Open Source Software Security Information Request', AWS suggested writing new code 'in a memory-safe language like Rust', but be aware that not all code written in a nominally memory-safe language is actually memory-safe... It's easy and fairly common for developers to disable compiler features that make Rust memory safe. ”
As a result, organizations such as CISA don't have a particularly good approach, saying simply, "We encourage others to build on this analysis to further expand our collective understanding of the memory insecurity risks of open source software, evaluate ways to mitigate this risk (e.g., targeted rewriting of critical components in memory-safe language), and continue to work to push software manufacturers to take risk-reducing actions." ”
Industry Perceptions
Gunnar Braun, technical manager for the Software Integrity Group at Synopsys, said, "The report and its previous 'Memory Safety Roadmap Guide' put this issue to the company's C-level executives – and rightfully so. Software safety and security is no longer a purely technical issue. ”
According to Braun, many open-source programs run in resource-constrained embedded systems. If you can't change the programming language, it's important to use static code analysis and fuzzing tools to reduce memory safety risks.
"Some memory-safe languages, such as Rust or Go, have made their way into embedded systems, so I'm optimistic that C/C++ will one day be replaced in large numbers — but not today, not tomorrow," he says.
According to Omkhar Arasaratnam, General Manager of OpenSSF, "Memory safety issues are not unique to open source or closed-source software. It is a common problem with all modern software. There are many memory-safe languages available today, such as JavaScript, Python, and Java, but software engineers often use older languages that are memory-insecure, such as C/C++, for performance or low-level hardware access. In addition, although Rust has emerged in recent years as a viable alternative to C/C++ in low-level systems programming, there are many embedded systems and safety-critical applications that are not a good fit for Rust."
He adds, "While it's entirely possible to write memory-safe code in memory-insecure languages, 25 years of CVE have taught us that this is highly unlikely, not that people are terrible programmers, but that it's very difficult to write memory-safe code in memory-insecure languages." ”
In the opinion of some developers, "It's a really good reminder that non-memory-safe legacy languages aren't going away." Indeed it is! While it's best not to write certain projects in low-level languages, they already exist, and rewriting is a huge undertaking that can introduce other logical errors. A better way to develop is to use tools and actually use them to fix some critical existing code. ”
It has also been argued that:
"Memory-safe languages, while designed to reduce the risk of memory leaks, can still actually occur. Sometimes, something like C (or C++) tends to have simple problems, but these are relatively easy to solve. Of course, you'll still need a good test suite to ensure code quality, but once you've done a memory cleanup with a tool like valgrind, it's relatively easy to keep your code under control and deal with new bugs.
Despite not being familiar with Rust, Java programmers have had problems using libraries they can find. They may not have a good understanding of the specific libraries they use, so they can experience serious memory leaks. While their test cases may run fine on their own machines, for enterprise-level software, these issues can multiply, and excessive memory usage can still cause system crashes. ”
In the age of AI, it has even been suggested that "instead of rewriting programs in memory-safe programming languages, AI can help catch some security vulnerabilities." ”
What do you think of the reports released by CISA and other institutions in the United States? Does programming language security directly improve program security? Feel free to leave a comment to share your insights.
Reference:
https://www.theregister.com/2024/06/28/cisa_open_source/
https://www.darkreading.com/application-security/cisa-memory-unsafe-code-open-source-projects
https://www.cisa.gov/sites/default/files/2024-06/joint-guidance-exploring-memory-safety-in-critical-open-source-projects-508c.pdf