Tech

Most critical open source projects not using memory-safe code

The US Cybersecurity and Infrastructure Security Agency (CISA) has released a study examining 172 key open source projects and whether they are susceptible to memory flaws.

The report, co-signed by CISA, the Federal Bureau of Investigation (FBI), as well as Australian (ASD, ACSC) and Canadian (CCCS) organizations, follows the “Case for Memory Safe Roadmaps” published in December 2023. aimed at raising awareness of the importance of memory-secure code.


Memory security

Memory-safe languages ​​are programming languages ​​designed to avoid common memory-related errors, such as buffer overflows, use-after-free, and other types of memory corruption.

They achieve this by automatically managing memory instead of relying on the programmer to implement secure memory allocation and deallocation mechanisms.

A modern example of a safe language system is Rust’s borrow checker, which eliminates data races. Other languages ​​like Golang, Java, C#, and Python manage memory through garbage collection, automatically reclaiming freed memory to prevent exploitation.

Memory risky languages ​​are those that do not provide built-in memory management mechanisms, placing this responsibility on the developer and increasing the risk of errors. Examples of such cases are C, C++, Objective-C, Assembly, Cython and D.

Widely used and dangerous open source code

The report presents research examining 172 widely deployed open source projects, revealing that more than half contain memory-hazardous code.

The main findings presented in the report are summarized as follows:

  • 52% of critical open source projects analyzed contain code written in memory-insecure languages.
  • 55% of the total lines of code (LoC) in these projects are written in memory-insecure languages.
  • The largest projects are disproportionately written in memory-insecure languages.
  • Of the ten largest projects in terms of total LoC, each has a proportion of unsecured LoC for memory greater than 26%.
  • The median proportion of insecure memory LoCs in these large projects is 62.5%, with four projects exceeding 94%.
  • Even projects written in memory-insecure languages ​​often depend on components written in memory-insecure languages.

Notable examples from the set reviewed include Linux (95% insecure code ratio), Tor (93% insecure code ratio), Chromium (51% insecure code ratio), MySQL Server (84% insecure code ratio), glibc (85% ratio), Redis (85% ratio), SystemD (65%), and Electron (47%).

Summary of findings
Source: CISA

CISA explains that software developers face multiple challenges that often force them to use memory-insecure languages, such as resource constraints and performance requirements.

This is especially true when implementing low-level features such as networking, cryptography, and operating system functions.

“We observed that many critical open source projects are partially written in memory-insecure languages ​​and limited dependency analysis indicates that projects inherit code written in memory-insecure languages ​​through dependencies,” CISA explains in The report.

“When performance and resource constraints are critical factors, we have seen and anticipate the continued use of memory-insecure languages.”

The agency also highlights the problem of developers disabling memory security features, either by mistake or on purpose, to meet specific requirements, leading to risks even when using theoretically more secure building blocks.

Ultimately, CISA recommends that software developers write new code in memory-safe languages ​​such as Rust, Java, and GO and port existing projects, especially critical components, to these languages.

Additionally, it is recommended to follow safe coding practices, carefully manage and audit dependencies, and perform continuous testing, including static analysis, dynamic analysis, and fuzz testing, to detect and resolve issues memory security.

News Source : www.bleepingcomputer.com
Gn tech

Back to top button